feat(sso) expired token session redirect

[dimetron]

Improve SSO expired token redirect (#2045)

This pull request implements robust handling of SSO session expiry in the UI when deployed behind an OIDC proxy (such as oauth2-proxy). The main improvements are the introduction of a clear authentication status model, transparent re-authentication when the session expires, and safeguards against redirect loops. The changes ensure users are not unexpectedly logged out when their forwarded token expires, while avoiding infinite redirects in unsecured (no proxy) environments. Comprehensive unit tests and documentation updates are included.

Authentication state handling and re-authentication flow:

• Introduced an explicit AuthStatus model ("authenticated", "expired", "unsecured") and updated getCurrentUser to return a structured AuthResult reflecting these states. This allows the UI to distinguish between a missing proxy, an expired token, and a valid session. [1] [2]
• Updated AuthProvider in AuthContext.tsx to trigger a redirect to the OIDC re-auth endpoint (/oauth2/start) only when the session is "expired", never in "unsecured" mode. Added a sessionStorage-based guard to prevent redirect loops if re-authentication fails to refresh the token. The guard is cleared on successful authentication. [1] [2] [3]

Testing and reliability:

• Added comprehensive unit tests for getCurrentUser to cover all authentication states, ensuring correct status assignment and token handling.
• Added tests for AuthProvider to verify redirect and guard logic, including prevention of redirect loops and correct guard clearing on authentication.

Documentation and UI updates:

• Updated the architecture documentation and added a new design doc to explain the three authentication states, the re-authentication flow, and the rationale for the changes. The flowchart and rationale in OIDC_PROXY_AUTH_ARCHITECTURE.md were updated for clarity. [1] [2]
• Minor UI alignment: adjusted the login page to match the new SSO redirect path and improved layout consistency.

These changes collectively ensure a seamless and predictable authentication experience for users behind SSO, while maintaining safe behavior in unsecured deployments.

[Copilot]

Pull request overview

This PR improves the UI’s behavior when running behind oauth2-proxy by distinguishing “unsecured” (no proxy/header) from “expired” (proxy session valid but forwarded id_token expired) and triggering a guarded re-auth redirect for the expired case, instead of silently rendering a logged-out UI.

Changes:

• Change getCurrentUser() to return an { status, user } result (authenticated | expired | unsecured) instead of CurrentUser | null.
• Add status to AuthContext and implement a sessionStorage-based loop guard + redirect to /oauth2/start?rd=... when status is expired.
• Add unit tests for the new auth status model and AuthContext redirect/guard behavior; update auth architecture docs and add an EP describing the design.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
ui/src/contexts/AuthContext.tsx	Adds AuthStatus to context and performs guarded oauth2-proxy re-auth redirect on expired.
ui/src/contexts/tests/AuthContext.test.tsx	Tests redirect/guard behavior and the new status value exposed by the provider.
ui/src/app/login/page.tsx	Minor layout tweak on the login page container.
ui/src/app/actions/auth.ts	Introduces AuthStatus/AuthResult and returns structured auth state from getCurrentUser().
ui/src/app/actions/tests/auth.test.ts	Tests getCurrentUser()’s new { status, user } contract.
docs/OIDC_PROXY_AUTH_ARCHITECTURE.md	Documents the three auth states and the re-auth flow in the auth boundary diagram/rationale.
design/EP-2045-sso-session-expiry-redirect.md	Adds a design EP explaining the motivation, approach, and test plan.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mesutoezdil]

3 small questions

nr1// auth.ts : when decodeJWT returns null (malformed token), the function returns status: "expired". but a malformed token is not really expired, it is invalid. would it make more sense to have a third path here so the ui does not try to reauth on a broken token?

nr2// jwt.ts:isTokenExpired returns false when claims.exp is missing, so a token with no expiry is treated as valid forever. is that intentional? feels like it could be a risk if a token without exp somehow ends up here.

nr3// AuthContext.tsx :REAUTH_GUARD_WINDOW_MS is 10 seconds. if the oidc flow at the idp takes longer than that (slow network, slow idp), the guard expires and the user hits the error path instead of completing reauth. would 60 seconds be more appropriate here?

[dimetron]

Thanks @mesutoezdil — all three are fair points. Addressed in the latest commit:

nr2 (jwt.ts — missing exp): Agreed, valid-forever was a risk. isTokenExpired now treats a missing exp as expired. OIDC id_tokens are required to carry exp, so a token without one is non-compliant/garbled and should force re-auth rather than be trusted indefinitely.

nr3 (AuthContext.tsx — guard window): Bumped REAUTH_GUARD_WINDOW_MS from 10s → 60s to cover a slow IdP round-trip, so an in-flight re-auth isn't misread as a failed loop while still catching a fast redirect loop.

nr1 (auth.ts — malformed token → expired): Kept malformed-token handling on the expired path intentionally. Behind oauth2-proxy a malformed forwarded id_token almost always means the proxy needs to re-mint one, so re-running the OIDC flow is the correct recovery, and the sessionStorage loop-guard (now 60s) prevents thrashing if the proxy keeps forwarding a broken token (the user lands on the error path after one failed cycle instead of looping). A separate "invalid" status would behave identically to "expired" here, so I left it as one path to avoid added surface area — happy to split it out if you'd prefer the explicit state.

Also added ui/src/lib/__tests__/jwt.test.ts covering decode (valid/malformed) and isTokenExpired (future/past/missing exp).