UI: “Sign in with <IdP>” link on "Not Authorized" page doesn’t start OIDC flow (requires 'Sign Out' first)

[ChefAustin]

Nomad version

$ nomad version
Nomad v1.11.1+ent
BuildDate 2025-12-09T20:27:42Z
Revision 1e6e5f5345106de7a1d510a076a1d8b3f52e6ea3

Operating system and Environment details

Nomad Nodes

• Ubuntu "Jammy" 22.04.5 LTS

Client Device

• macOS 26.2 (Build: 25C56)
• Google Chrome v144.0.7559.110 (Official Build) (arm64)

Issue

[Preface: It is possible that I am simply "holding it wrong" and that perhaps there is a config change that I need to make somewhere in order to make this more intuitive/work as expected. Apologies if that is the case and, if so, please feel free to direct me towards any docs which might aid me in configuring this properly.]

When ACLs are enabled and OIDC SSO is configured, an unauthenticated user who navigates to https://<nomadUrl.tld>/ui/ is redirected to https://<nomadUrl.tld>/ui/jobs and appears to be “logged in” as the anonymous user.

On the /ui/jobs page, the UI displays a “Not Authorized” state and a “Sign in with Okta” message, where the IdP name (“Okta”) is a link that navigates to:

• https://<nomadUrl.tld>/ui/settings/tokens

From a UX perspective, a link labeled “Sign in with Okta” strongly implies that clicking it will initiate the OIDC login flow. Instead, it takes the user to the Settings/Tokens UI for the anonymous session.

To actually initiate the OIDC SSO flow, the user must:

1. Click Sign Out (to end the anonymous session), then
2. Click the blue Sign in with Okta button to begin the IdP flow.

This is confusing/unintuitive because:

• The user is effectively “authenticated” (as anonymous) but not authorized
• The primary call-to-action presented as “Sign in with Okta” does not actually sign in
• The workaround (sign out first) is not obvious and feels like a broken login link

This feels like either:

• a UX bug (misleading link target / incorrect CTA wiring), or
• an opportunity to improve the login flow when anonymous sessions are present.

Reproduction steps

1. Run Nomad with:
   • ACLs enabled
   • OIDC auth configured and functioning with an IdP (Okta)
2. In a fresh browser session (no prior Nomad UI auth), navigate to:
   • https://<nomadUrl.tld>/ui/
3. Observe redirect to:
   • https://<nomadUrl.tld>/ui/jobs
4. Observe the UI renders in an “anonymous” session and displays “Not Authorized” and “Sign in with Okta”.
5. Click the “Okta” link in the “Sign in with Okta” text (navigates to /ui/settings/tokens).

Expected Result

One of the following behaviors would be a smoother UX:

• Clicking “Sign in with Okta” should initiate the OIDC login flow, or
• The “Not Authorized” page should present a clear single-step login CTA that initiates OIDC even if an anonymous session exists (i.e., the login action should “upgrade” the session without requiring a sign-out first), or
• If the link is intended to take the user to token/settings management, the text should not read “Sign in with Okta”; it should be labeled accordingly (e.g., “Manage tokens”) and a separate OIDC login CTA should be presented prominently.

More generally, when an unauthenticated user hits /ui/ with OIDC enabled, the UI should offer an obvious one-step path to authenticate via OIDC.

Actual Result

• User lands on /ui/jobs in an “anonymous” session
• UI shows “Not Authorized” and a “Sign in with Okta” message
• Clicking “Okta” does not initiate SSO; it navigates to /ui/settings/tokens for the anonymous session
• User must click Sign Out first, then click the blue Sign in with Okta button to start OIDC

Job file (if appropriate)

Not applicable

Nomad Server logs (if appropriate)

Not applicable

Nomad Client logs (if appropriate)

Not applicable

[mehrdadbn9]

Hi @mehrdadbn9, I'd like to work on this issue. Please assign it to me.