Client-side deletion removes the local copy of the token, but it does not remove the token's authority at the authorization server. If the refresh token remains valid server-side, it can still mint new access tokens until expiry. Effective logout requires server-side revocation and family invalidation, not just clearing storage.
Why client-only logout feels complete but is not
Client-side deletion only removes the token from local storage, memory, or the browser cache. It does not change the token’s status at the authorization server, so the server may still treat the token as valid until it expires or is explicitly revoked. That is why logout can appear successful locally while the session remains live in practice.
The key distinction is between removing a copy of a token and removing the token’s authority. If the refresh token is still accepted server-side, the client can often obtain fresh access tokens even after “logout.” In other words, the user has left the application interface, but the underlying authorization grant may still exist.
This problem is most visible in systems that rely on bearer tokens and refresh flows. Access tokens are usually short-lived, so local deletion may stop immediate reuse in the browser, but it does not invalidate a surviving refresh token, token family, or session record. The logout boundary is therefore an identity and authorization boundary, not just a storage operation.
What server-side revocation changes
Effective logout requires the server to stop honoring the credential path that can mint or replay access. In OAuth-based systems, that typically means revoking the refresh token, invalidating the token family where supported, and ensuring the authorization server no longer recognizes the grant. The practical goal is to remove future authority, not merely the current client copy.
That distinction also explains why different token types behave differently. A deleted access token may become unusable when it expires naturally, but a valid refresh token can extend the session indefinitely unless revocation or rotation logic breaks the chain. If the backend does not track or reject the token after logout, the client has only performed a local cleanup.
Logout design is therefore tied to trust boundaries. If the user can continue to refresh tokens after signing out, the application has not actually ended the session. A reliable logout flow must coordinate client state, token revocation, and session invalidation so that the server and client agree that the authority has ended.
Why “delete and forget” creates false assurance
Client-only logout often creates a false sense of closure because the visible symptom disappears first. The app may redirect to a signed-out page, clear its storage, and stop showing protected content, but another device, tab, or replay path may still possess an active credential. The user experience is clean, while the security state is not.
This gap matters even more when tokens are copied into multiple stores or reused across sessions. If refresh tokens are long-lived, stolen, or shared across environments, local deletion on one client does nothing to the token’s remaining authority elsewhere. The right question is not whether the browser forgot the token, but whether any accepted token remains that can still act for the user.
That is why revocation should be treated as an authorization-server responsibility with client cooperation, not as a UI feature. The client can request logout and discard local material, but only the server can remove the continuing right to mint new tokens.
Risk and Threat Considerations
Client-only logout can leave a valid refresh token or session grant intact, which means an attacker with copied token material may continue to obtain new access even after the user believes the session has ended. The failure is not just inconvenience, it is residual authority that can outlive the visible logout action.
Failure mechanism: The application clears local storage, but the authorization server still accepts the refresh token or session state. Any party holding that token path can continue token renewal until expiry, rotation failure, or explicit server-side revocation breaks the chain.
Impact: Users may believe access has ended when it has not, which increases the blast radius of token theft, shared-device use, abandoned sessions, and delayed incident response. In high-trust or high-value systems, that can preserve access long after the user expects it to be gone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Refresh-token revocation and lifecycle control are authenticator management concerns. |
| AC-2 — Account Management | Logout ends account session authority and should remove active access state. | |
| AC-12 — Session Termination | The question is about ending an authenticated session, not only clearing the client. | |
| Recommendation — Revoke and expire authenticators so logged-out credentials cannot mint new sessions. Invalidate active session state when users sign out or accounts are terminated. Terminate the server-side session when logout occurs, not just the browser copy. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | A surviving refresh token means authentication remains effective after logout. |
| API5 — Broken Function Level Authorization | If logout does not remove authority, functions may still be reachable through token renewal. | |
| Recommendation — Invalidate authentication state server-side so token renewal stops after logout. Restrict post-logout functions by invalidating the session that authorizes them. | ||
| OWASP ASVS | V7 — Session Management | Logout is fundamentally a session termination and token invalidation problem. |
| Recommendation — Bind logout to session invalidation and verify stale tokens cannot be reused. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | A refresh token that survives logout behaves like long-lived secret material. |
| Recommendation — Shorten token lifetimes and revoke long-lived credentials on logout. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator Management | This is about managing authenticators so they stop working after sign-out. |
| Recommendation — Disable or revoke authenticators that should not remain valid after logout. | ||
Practitioner Guidance
What to verify: Confirm that logout triggers a server-side action, not just client cleanup. The test is whether a previously issued refresh token can still obtain new access after sign-out, because that is the clearest signal that logout is incomplete.
What good looks like: A proper logout flow ends the server-recognized session, invalidates the refresh path, and prevents token renewal from any remaining copy of the credential. If the system supports token rotation, revocation should also sever the token family so old material cannot be reused.
Decision rule: If your architecture uses refresh tokens, treat client-side deletion as necessary but insufficient. Require a backend revocation or session invalidation step for every logout path that is meant to end authority, not just hide the authenticated UI.
Practitioner takeaway: Logout succeeds only when the server no longer recognizes a live authorization path; deleting the client copy removes convenience, but revoking server-side authority removes risk.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org