Backoffice auth flow: architectural improvements for login, timeout, and logout

[iOvergaard]

Context

The backoffice authentication flow currently serves multiple distinct UX scenarios through a single code path. While functional, the architecture has accumulated friction points as requirements have grown (multi-provider support, timeout recovery, multi-tab coordination, OpenIddict constraints). This issue documents the tensions and proposes a direction for future improvements.

Related: #21846 (current PR addressing some symptoms), umbraco/Umbraco.UI#1292 (UUI closable property)

The scenarios

The auth system must handle these distinct flows, each with different UX requirements:

Flow	Context	Transport	Can redirect?	Must preserve state?
Initial login	Fresh page load, single provider	Full-page redirect	Yes	No
Multi-provider login	Fresh page load, multiple providers	Modal → redirect	Yes	No
Timeout recovery	Modal over user's work	Popup	No (loses SPA)	Yes
Explicit logout	/umbraco/logout route	Page component	Yes	No
401 recovery	API call fails mid-session	Transparent refresh	No	Yes

Today, these are funneled through UmbAppAuthController.makeAuthorizationRequest() → #showLoginModal() → UMB_MODAL_APP_AUTH → umb-auth-view, with branching based on userLoginState. The branching works, but it means one component and one modal token carry the complexity of all five flows.

Architectural tensions

1. Modal vs page duality

umb-auth-view renders the same UI whether it's inside a modal (timeout) or as a standalone page (logout route). But the two contexts have different requirements:

• Modal: must not be dismissable, must not redirect, must fire onSuccess callback to submit the modal
• Page: can redirect freely, doesn't need a callback, should integrate with the router

The view doesn't know which context it's in — it just receives userLoginState and an onSuccess callback. This works but makes it hard to optimize either path independently.

2. Redirect vs popup is coupled to login state

The transport mechanism (redirect vs popup) is determined by userLoginState:

const isTimedOut = this.userLoginState === 'timedOut';
await authContext.makeAuthorizationRequest(providerName, isTimedOut ? false : true, ...);

This coupling means the view is making a transport decision based on UI state. If we ever need a non-redirect flow for a non-timeout case (or vice versa), this breaks down.

3. Token expiry calculation inconsistency

Token lifetime is calculated differently in two places:

• SharedWorker (token-check.worker.ts): uses issuedAt + expiresIn * TOKEN_EXPIRY_MULTIPLIER (4)
• TokenResponse.isValid(): uses issuedAt + expiresIn (no multiplier)

This means the main thread considers a token expired before the worker does, or vice versa, leading to edge cases where refresh attempts and timeout detection disagree.

Tip

This is being addressed in PR #21830

4. Multi-tab token refresh is uncoordinated

When multiple tabs are open and a token expires:

• Each tab's worker instance may simultaneously detect expiry
• Multiple tabs may attempt makeRefreshTokenRequest() concurrently
• The storage event listener syncs the result, but the race is wasteful and can cause flickering timeout modals

Web Locks (navigator.locks.request) would give single-writer semantics for token refresh, but aren't currently used for this.

Tip

This is being addressed in PR #21830

5. Non-dismissable modal is a workaround

The auth modal must not be closable via ESC, but UUI's UUIModalDialogElement always binds cancel → close. We currently work around this with a custom subclass that overrides _openModal() internals (#21846, tracked upstream in umbraco/Umbraco.UI#1292). This is fragile — it duplicates parent behavior and will break if UUI refactors.

Suggested direction

These don't all need to happen at once, but they point toward a cleaner architecture:

Separate the flows: Instead of one modal token with branching, consider distinct entry points:

• A timeout recovery controller that owns the modal lifecycle, popup transport, and state preservation
• A login page (route component) that handles initial login and logout with standard redirects
• A shared auth provider picker component used by both

Decouple transport from state: Let the controller/context decide redirect vs popup based on the flow type, not the view. The view should just say "authenticate with this provider" and not care how.

Unify token expiry: Single source of truth for token lifetime calculation, shared between worker and main thread.

Coordinate multi-tab refresh: Use Web Locks for token refresh to ensure only one tab refreshes at a time, with others waiting for the result via storage events.

UUI closable property: Once umbraco/Umbraco.UI#1292 lands, replace the custom subclass with a simple config flag.

Non-goals

This issue is not proposing:

• Replacing OpenIddict or the OAuth flow
• Changing the server-side token lifetime or refresh behavior
• Rewriting the auth system from scratch

The goal is incremental improvement — untangling concerns so each piece is simpler to reason about and maintain.

[dev-miro26]

Hello @iOvergaard ,
Hope you are doing well.
Could you please assign this issue to me?
Thanks

[iOvergaard]

This is not something we can work on just yet. I have converted it to a discussion for the time being.