The user interface says the session ended, but the identity session may still exist at the provider or token layer. That leaves refresh tokens, browser sessions, or cached auth state usable after the player believes they are signed out.
What actually keeps the session alive after a client-side logout?
A client-side logout usually clears what the browser or app knows, not what the identity provider, token service, or upstream session store still considers valid. If the server-side session, refresh token, or federated login state remains active, the user can appear signed out while authentication still succeeds elsewhere.
That mismatch is why client-only logout often fails to end access consistently across tabs, devices, embedded browsers, and other applications that rely on the same identity session.
Why refresh tokens and browser sessions are the usual break point
The most common failure is that the visible application state changes, but the underlying credential remains usable. A refresh token can mint new access tokens after the UI has been cleared, and a provider session can silently re-authenticate the user on the next redirect or page load.
In OAuth-based flows, the browser is often just the last place where the user sees state, while the real authority sits with the authorization server. The core protocol in RFC 6749: The OAuth 2.0 Authorization Framework separates client behavior from token issuance, which is why a local logout cannot be assumed to revoke upstream trust. When tokens are bound to client authentication or certificates, as described in RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, the logout problem becomes a question of server-side invalidation, not just UI teardown.
What you need to invalidate to make logout real
Real logout means removing every active path that can still prove the user is signed in. That usually includes browser cookies, refresh tokens, provider sessions, and any cached authentication state in adjacent apps that share the same identity layer.
In federated environments, front-channel logout and back-channel logout behave differently, and neither should be treated as automatic by the client alone. Audience restriction and resource targeting, such as in RFC 8707: Resource Indicators for OAuth 2.0, can reduce token misuse, but they do not replace explicit revocation or session termination at the authority that issued the credential.
Risk and Threat Considerations
Client-only logout creates a false assurance problem: the user thinks access ended, but the credential or session may still be valid enough to authorize requests. That is especially dangerous where refresh tokens, shared browser profiles, or cross-application SSO make the surviving session reusable.
Failure mechanism: The application clears local state while the identity provider, token service, or browser session continues to recognize the user, allowing silent re-authentication or token refresh after logout.
Impact: An attacker with access to the device, browser, or stolen token can keep using the account after the user believes it is signed out, and incident response will often miss the exposure if only client logs are checked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Logout failure is a session offboarding gap for non-human or federated identities. |
| Recommendation — Revoke upstream sessions and tokens when sign-out is requested. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Logout depends on invalidating or expiring authenticators and token material. |
| IA-9 — Service Identification and Authentication | Token-based and federated flows keep access alive beyond the client UI. | |
| Recommendation — Expire or revoke credentials and tokens when the session ends. Enforce server-side session termination for authenticated services and APIs. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Client-only logout can leave API auth valid after the user believes it ended. |
| Recommendation — Invalidate server-side authentication state when logout occurs. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Identity session and authenticator lifecycle determine whether logout truly ends access. |
| Recommendation — Align logout behavior with the provider's session and authenticator lifecycle. | ||
Practitioner Guidance
What to verify: Confirm that logout invalidates or expires the upstream session, not just the app session. Test the post-logout path by attempting a token refresh, opening a new tab, and reloading the identity provider flow.
Decision rule: If the same identity can still obtain new access without fresh user interaction, treat logout as incomplete and fix the server-side revocation path before considering the control effective.
Practitioner takeaway: A trustworthy logout is measured by whether the next authentication attempt is actually forced, not by whether the interface happens to look signed out.
Related resources from NHI Mgmt Group
- How should security teams implement Client ID Metadata Documents?
- What usually breaks when teams bolt authentication onto a game client too late?
- What breaks when plugin permissions are handled by each client separately?
- What breaks when OAuth tokens are not handled correctly in client applications?