A “log out all devices” action works only when the server rejects every credential that could still authorize a request. Clearing the cookie in the current browser is not enough. If the server still accepts the old session identifier, a copied cookie keeps working on another device. OAuth tokens follow the same rule with an extra wrinkle: revoking a refresh token stops new access tokens from being issued, but an access token that the resource server validates on its own can keep working until it expires, unless that server checks for revocation. Proper revocation therefore means changing server-side state for each credential type, then testing the old credentials against every service that accepts them.
Where the logout boundary actually sits
“All devices” is not one object. A typical account has several layers of state, and each can end on its own schedule:
As an Amazon Associate I earn from qualifying purchases.
- Application session: the server-side record, or the signed token, that the web or mobile app uses to recognize a signed-in user.
- Identity-provider session: the sign-in state held by the identity provider that the application delegates to. Ending the application session does not automatically end this one.
- OAuth grant: the authorization a user gave a client application, which the authorization server records and can revoke.
- Refresh token: the long-lived credential used to obtain new access tokens.
- Access token: the short-lived credential presented to APIs and resource servers.
- Relying services: other applications that trust the same identity provider and may keep their own local sessions.
A logout-all feature that touches only the first item will look successful in the interface while leaving the rest open. The sections below work through each layer.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallMap every credential before changing code
Start with an inventory. For each credential, identify the component that validates it and the event that actually ends it. The table below sets out the typical pattern; confirm each row against your own deployment, because the cited standards describe requirements and options rather than a single implementation.
#1 Best Overall
| Credential | Validated by | What ends it | Common gap |
|---|---|---|---|
| Browser session cookie holding an opaque session ID | Application server looking up the session store | Server marks the session record revoked or deletes it | Cookie deleted in one browser while the server still accepts the old ID elsewhere |
| Self-contained session token (signed, stored in a cookie or app storage) | Every service that verifies the signature | Expiry, or one of the server-side controls covered below | No natural early end; an unexpired token keeps verifying |
| OAuth refresh token | Authorization server | Revocation request, refresh-token rotation logic, or revocation after a password change or logout at the authorization server | Revocation stops new access tokens, not tokens already issued |
| OAuth access token, self-contained (for example, a signed JWT) | Resource server, locally, without a call to the authorization server | Expiry; early revocation is seen only if the resource server checks for it | A revoked token can still verify until expiry |
| OAuth access token, checked by introspection | Resource server asking the authorization server about the token’s current state | Revocation at the authorization server | Latency and availability depend on how often each resource server asks |
| Remember-me or persistent login token | Application server | Not stated by the cited standards; it needs its own revocation record | Often forgotten because it is not called a “session” |
| Identity-provider session | Identity provider | Provider’s own logout behavior, which varies by product and configuration | Application logout does not end it unless logout is propagated |
Also record which services accept each credential. A token issued for one API may be accepted by three others, and each of them needs to reject it.
Invalidate server-side session state
For stateful sessions, the logout-all operation should change the session record itself rather than only the browser. OWASP’s Web Security Testing Guide treats proper server-side invalidation as a core part of secure session termination, and it warns that changing the browser cookie while leaving the old server-side session active lets a copied cookie be reused.
NIST SP 800-63B-4 (Session Management) states that session-binding secrets must be erased or invalidated when the subscriber logs out. It also recommends HTTPS-only cookie delivery with limited host and path scope, and says cookie expiration should not be relied on to enforce session timeout. Cookie cleanup improves the client’s state; it does not replace server enforcement.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →In practice:
- Update the session record to a revoked state, or delete it, in one atomic write. A two-step update can leave a window in which the session is half-ended.
- Make sure every application node reads that state. A load balancer that spreads requests across servers with separate in-memory caches can keep serving an old session after the database says it is revoked.
- Set a cache lifetime you can justify. If a cache holds session state for 60 seconds, the reader’s “immediate” logout can take up to 60 seconds to take effect on that node, so decide whether that delay is acceptable or invalidate the cache entry at revocation time.
- Clear the cookie on the client as well, using the same secure attributes the session was set with.
Handle self-contained tokens that cannot be recalled
A signed token verifies without a database call, which is why it scales well. The same property means a server cannot delete it. Expiry is the only natural end, so anything that must stop before expiry needs an extra control. OWASP ASVS 5.0 lists three approaches recognized for this purpose:
- Terminated-token list. Store the identifiers of revoked tokens and reject any token found on the list. Every validator must check the list, and the list must be kept until the tokens would have expired anyway.
- Per-user cutoff time. Store a date and time for each user, and reject any token issued before it. Logout-all sets the cutoff to now. This is a single value per user and needs no per-token list, but it also rejects tokens issued just before the logout for that user, including tokens from devices the user is still using.
- Per-user signing key rotation. Sign each user’s tokens with a key that can be replaced. Replacing the key invalidates that user’s outstanding tokens. Validators must receive the new key promptly, and cached copies of the old key must be retired on a known schedule.
Whichever approach you choose, every service that accepts the token must enforce it. A cutoff checked by the web tier but not by the API tier is a gap, not a partial fix. Pair any of these with short token lifetimes so that the window in which a missed validator matters stays small.
Revoke OAuth grants and token families
RFC 7009 defines the OAuth token revocation endpoint. It requires support for revoking refresh tokens and recommends support for revoking access tokens. A revocation request can also invalidate related tokens and the underlying authorization grant, which is what makes it useful for logout-all: one request can end a whole family of credentials, provided the authorization server implements that behavior.
The limit is the one described above. RFC 7009 does not make a self-contained access token disappear from resource servers that validate it locally. Refresh-token revocation prevents new access tokens, but it is not, by itself, an immediate logout at every resource server.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
RFC 9700, the OAuth 2.0 Security Best Current Practice, describes refresh-token rotation and discusses refresh-token expiration and revocation. It permits authorization servers to revoke refresh tokens after security events such as a password change or logout at the authorization server. Use that behavior deliberately. A logout sequence that works in a clear order is more reliable than one that depends on timing:
- Revoke the application session on the application server.
- Call the authorization server’s revocation endpoint for the refresh token, and for the access token if the server supports it.
- Propagate logout to the identity provider and to relying services, where your federation setup supports it.
- Apply the chosen access-token control, such as a cutoff or introspection, so that tokens already issued stop working at resource servers as far as your design allows.
Check the authorization server’s response to each step and record failures. A revocation call that returns an error that your code ignores leaves the credential live without any visible sign.
Define “all devices” in product terms
OWASP ASVS 5.0 expects users to be able to view their active sessions and terminate them, and it expects session termination to require reauthentication where appropriate. It also addresses ending sessions after an account is disabled or deleted and after changes to authentication factors. Those requirements shape what “all devices” should mean in your product.
- Include every application session and token family that belongs to the user, including mobile and API credentials.
- Include the relevant federation and relying-party sessions, or state clearly that they are excluded.
- Name the services that cannot be controlled from your side, so that users are not told that everything has ended when it has not.
- Decide whether the currently active device is also signed out. Many products keep it signed in to avoid surprising the user, and that choice should be explicit.
Test revocation, not just the button
A passing user-interface test proves little. The useful test replays the old credentials. Use two test accounts or two devices in a non-production environment, and keep the steps below.
- Sign in on device A and device B. From device B, capture the session cookie and any access and refresh tokens the client holds.
- Confirm that device B can call a protected endpoint with those credentials.
- From device A, trigger “log out all devices”.
- Replay device B’s cookie and tokens against the application, every API, and each relying service. Expected result: each request is rejected with an authentication error.
- Attempt to refresh using device B’s refresh token. Expected result: the authorization server refuses to issue a new access token.
- Replay device B’s access token against each resource server, first immediately and then after your cache lifetime has passed. Record any service that accepts it, and whether that acceptance ends at the token’s expiry time.
- Repeat the replay with a single-device logout, an expired session, a password change, an MFA change, and an account disablement. Each should produce the same rejection, with the exception of any single-device case you intentionally scoped differently.
OWASP ASVS 5.0 (V7.4.1) states the expected outcome in one line: “Verify that when session termination is triggered (such as logout or expiration), the application disallows any further use of the session.” Your test plan should be able to show that for every credential in your inventory.
Best Value
Troubleshooting when an old credential still works
- The old cookie is accepted by one node. The node is probably reading a cached copy of the session. Check the cache lifetime and whether revocation invalidates the entry.
- The old cookie is accepted after a deletion. The session may be deleted in the database but still present in a replica or a secondary store. Confirm which store the validator reads.
- A refresh token still mints access tokens. The revocation call may have been made for the wrong token, or rotation may not have revoked the token family. Inspect the authorization server’s response and the token’s grant record.
- An access token works on one API for its full lifetime. That API verifies the token locally and has no revocation check. Add a terminated-token list, cutoff, or introspection to that API, or shorten token lifetimes as an interim measure.
- The user is still signed in on a relying service. The identity-provider session or the relying party’s local session was not ended. Check whether logout is propagated, and document the service if it cannot be reached.
- Old tokens stop working only after a signing-key change. Validators may be holding the old key in cache. Confirm that key distribution and cache expiry match your rotation plan.
Scope of this guidance
The guidance above follows NIST SP 800-63B-4 for session management, RFC 7009 for OAuth revocation semantics, RFC 9700 for current OAuth security practice, OWASP ASVS 5.0 for verification requirements, and the OWASP Web Security Testing Guide for test cases. Exact behavior depends on the product, identity provider, and token format you use. Consult your provider’s current documentation before relying on any product-specific logout setting, because these behaviors change with versions and configuration.
Done properly, logout-all is a set of state changes across every credential and service, verified by replaying the credentials that were meant to die. Anything less leaves a copy of the old session working somewhere.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
