Auth: Skip /token refresh when access token is still valid

[iOvergaard]

Summary

• Skip /token when access token is still valid — configureClient()'s auth callback and getLatestToken() now guard with #isAccessTokenValid(), so the token endpoint is only hit when the access token has actually expired. Previously every API request triggered a refresh regardless, causing unnecessary token churn and OpenIddict ID2019 errors on in-flight requests.

• Wait for ongoing cross-tab refresh — when the access token is valid but another tab holds the umb:token-refresh Web Lock (proactive refresh via keepUserLoggedIn), the auth callback now waits for that refresh to complete before proceeding. This restores the cross-tab serialization that the guard above removed, preventing requests from being sent with a token that is about to be revoked.

• Remove redundant first-check validateToken() on startup — UmbAppAuthController.isAuthorized() previously called validateToken() on the very first guard evaluation, producing a second /token call immediately after setInitialState() had already verified the session. This was a leftover from the AppAuth/localStorage era. setInitialState() now owns server verification; stale peer-sourced sessions are handled lazily by the 401 interceptor.

How each caller behaves after these changes

Caller	Behaviour
configureClient() auth callback (per request)	Skips /token when access token valid; waits if another tab is refreshing
getLatestToken() (deprecated, userland)	Same as above
UmbAuthSessionTimeoutController → validateToken()	Unchanged — always calls makeRefreshTokenRequest() for proactive refresh
app-auth.controller.ts startup guard	Removed redundant first-check; setInitialState() is authoritative

Why the popup re-auth path doesn't call /token from the main window

After timeout → popup re-auth, the popup's authorization_code exchange calls /token and the server's HideBackOfficeTokensHandler writes fresh encrypted cookies to the response. Cookies are domain-scoped, so the main window has the new cookies immediately — no separate /token call needed. The "Stay logged in" button takes a different path (refresh_token grant directly from the main window), but both paths end with equivalent fresh cookie state.

Test plan

• Navigate between sections — /token should only fire when the access token expires, not on every request
• With keepUserLoggedIn=true: open two tabs, verify only one /token call fires per proactive refresh cycle (no ID2019 on the other tab)
• Let the session timeout naturally → re-auth via popup → verify the encrypted cookie value changes and subsequent requests succeed without errors
• Click "Stay logged in" in the timeout modal → verify /token is called and the session timer resets
• Verify startup has exactly one /token call (not two)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR reduces unnecessary /token refresh calls in the backoffice client by avoiding validateToken() refreshes on every API request when the in-memory access token is still valid, aiming to reduce token endpoint load and mitigate OpenIddict ID2019 errors caused by frequent token revocation.

Changes:

• Guard getLatestToken() to call validateToken() only when #isAccessTokenValid() is false.
• Guard the OpenAPI client auth callback in configureClient() similarly, so requests don’t trigger refresh while the access token is still valid.