What usually breaks when logout is only handled in the client?

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.

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?