PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated 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 matchiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A “log out all devices” action only works if the server invalidates every credential that can still authorize a request. Clearing the cookie in the current browser is not enough. In most failures, the old session identifier still validates on the server, a refresh token keeps issuing new access tokens, or a self-contained access token keeps working at an API until it expires. Session revocation is done properly when the application session store, every token type, and every service that validates those credentials all agree that the old access has ended.
Why an old session still works after logout
Logging out is a server-side state change. It makes the previous credential unusable, which is different from removing that credential from the browser. The OWASP Web Security Testing Guide treats proper server-side invalidation as a core part of secure session termination, and it specifically warns that changing the browser cookie while the old server-side session stays active lets a copied cookie be reused.
The reason “log out all devices” fails in practice is that a user’s access is spread across several layers, and each layer can end on a different schedule:
| Layer | Where state lives | What “log out all” must do | Typical failure if skipped |
|---|---|---|---|
| Browser session cookie | Client | Expire it in the current browser, and invalidate the server record it points to | Cookie is cleared locally while a copied value still loads the account |
| Server-side application session | Session store | Mark the record revoked or delete it atomically; every application node checks it | One node or a cache still treats the session as active |
| Remember-me or persistent login token | Client and server store | Revoke every persistent login record for the user | A long-lived cookie silently recreates a new session |
| OAuth refresh token | Authorization server | Revoke it through the revocation endpoint | The client keeps minting new access tokens |
| Opaque OAuth access token | Authorization server | Revoke it, or make resource servers check its status | A resource server accepts it until expiry, or from a cache |
| Self-contained (JWT) access token | Validated locally by each resource server | Block it with a terminated-token list, a per-user cutoff, or a signing-key change, or rely on a short lifetime | Revocation is invisible to the resource server until the token expires |
| Identity-provider session | Identity provider | End the provider session where federated sign-in applies | Single sign-on signs the user back in without a password prompt |
| Relying-party sessions | Federated services | Propagate termination, or disclose which services keep their own session | A federated service stays logged in after the rest of the account is closed |
Each row has different termination behavior, so one “delete session” call cannot cover all of them. The sections below work through them in the order an engineering team usually needs them.
#1 Best Overall
Step 1: Map every credential that can authorize a request
Before changing code, list every credential the user can hold and which component validates it. For most applications this includes:
- Browser session cookies and the server-side session IDs they reference
- Remember-me or persistent login tokens
- OAuth access tokens and refresh tokens, including those held by mobile apps
- Identity-provider sessions used for single sign-on
- Service-specific credentials, such as API keys or tokens issued to a backend service on the user’s behalf
NIST SP 800-63B-4 warns that access tokens and their associated refresh tokens can outlive the authentication session they were issued under. That gap is the usual reason a logout that clears the session still leaves API access in place. Record, for each credential, its lifetime, its validator, and whether a validator can see a revocation in time.
Step 2: Invalidate server-side state
Stateful sessions
For opaque session identifiers that the server looks up on each request, revocation is direct: write the revoked state, or delete the record, in a single atomic operation. Then confirm the write is visible to every application node, worker, and cache that performs session checks. A session store that is replicated asynchronously, or an in-memory store on one node, can keep honoring a session after the user has logged out everywhere.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The cookie should also be cleared for the browser that initiated the request, and it should be issued with attributes that limit exposure. NIST recommends HTTPS-only delivery and limited host and path scope. A typical session cookie looks like this:
Set-Cookie: __Host-sid=<opaque_session_id>; Path=/; Secure; HttpOnly; SameSite=LaxThe __Host- prefix requires the Secure attribute and Path=/, and it forbids a Domain attribute, which keeps the cookie bound to one host. NIST also says cookie expiration should not be relied upon to enforce session timeout. Clearing the cookie improves the client state, but the server must still reject the old value.
NIST states the requirement for session-binding secrets directly: “Secrets are erased or invalidated by the session subject when the subscriber logs out.” Treat that as a requirement on both the browser and the server.
Self-contained tokens
A signed token that carries its own expiry and claims is efficient because each resource server can validate it locally, without calling the issuer. The cost is that local validation cannot see a later logout. Until the token expires, the resource server has no built-in way to know the user revoked access.
Free tools Windows power users keep installed
One-click scans. No signup required.
OWASP ASVS 5.0 lists three approaches that block such tokens before expiry. Choose one, and make sure every validator enforces it:
- Terminated-token list: keep a list of revoked token identifiers, and reject any token that appears on it. Entries can be removed once the token would have expired anyway.
- Per-user cutoff: store a timestamp for the user’s logout-all event, and reject any token issued before it.
- Per-user signing key rotation: sign tokens for each user with a key that can be rotated, so that rotating the key invalidates that user’s outstanding tokens.
Each option requires a shared lookup or key-management step, which means the validators need current state. Account for cache propagation: a resource server that caches the cutoff or denylist for several minutes will accept a token for those minutes after logout. Account also for key-rotation behavior, because a rotation that invalidates all users’ tokens at once is a different operation from rotating one user’s key.
Step 3: Revoke OAuth grants and token families
Refresh tokens stop new access tokens
RFC 7009 defines a token revocation endpoint. Support for revoking refresh tokens is required, and support for revoking access tokens is recommended. A revocation request can also invalidate related tokens and the underlying authorization grant, which is what stops a client from quietly minting replacements.
A revocation call has this shape, sent by the client that received the token:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →POST /oauth/revoke HTTP/1.1
Content-Type: application/x-www-form-urlencoded
token=<refresh_token>&token_type_hint=refresh_tokenThe path shown is illustrative. Use the revocation endpoint published in your authorization server’s metadata. Confidential clients must authenticate the revocation request, as RFC 7009 requires, and the authorization server’s response should be connected to your application’s logout flow so that the local session is ended only once revocation has been requested.
Access tokens and the propagation gap
Revoking a refresh token does not, by itself, log out a resource server that already accepts an issued access token. RFC 7009 leaves that validation behavior to the resource server, and with self-contained tokens the resource server may not learn about the revocation until expiry. If the security requirement is immediate termination, use one of these controls:
- Short access-token lifetimes, so that the exposure window is bounded by design
- Online introspection or a revocation check on each request, so the resource server asks the authorization server about the token’s current status
- A shared denylist or per-user version value, as described in the self-contained token section above
Do not describe refresh-token revocation as an immediate logout of every resource server. Document the maximum delay that applies to your deployment.
Authorization server policy
RFC 9700, the current OAuth security best current practice, covers refresh-token rotation, expiration, and revocation. It permits authorization servers to revoke refresh tokens after security events such as a password change or a logout at the authorization server. Align three things: application logout, identity-provider logout, and grant revocation. Where they are not aligned, the user will see a logout that appears complete in one place and not in another.
Define “all devices” in product terms
Users need to know what the button covers. 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 terminating sessions after an account is disabled or deleted and after changes to authentication factors. A “log out all devices” action that ignores a password or MFA change leaves a gap that ASVS treats as a session-management problem.
A practical definition includes every application session for the account, every remember-me record, and every refresh-token grant issued for the account’s applications. It should also state whether federated relying services and the identity provider’s own session are included. If some services are outside your control and cannot be terminated, say so in the interface rather than implying a complete logout.
ASVS V7.4.1 states the core expectation: “Verify that when session termination is triggered (such as logout or expiration), the application disallows any further use of the session.”
Test revocation, not just the button
A successful response from the logout endpoint does not prove that old credentials are dead. Test with credentials captured before the logout:
Recommended Free Tools
- Sign in on a second browser or device, and capture the session cookie, access token, and refresh token for that session.
- In the first browser, trigger “log out all devices.”
- Replay the saved session cookie against a protected page and against the protected API endpoints. Each should be denied.
- Replay the saved access token against every resource server that accepts it, including any cached paths, and confirm denial within the delay you documented.
- Attempt a refresh with the saved refresh token. The request should fail.
- Check federated relying-party sessions and the identity-provider session, if your product includes them.
- Repeat the replay checks after a password reset, an MFA change, and an account disablement, because ASVS expects termination after those events too.
OWASP’s testing guidance emphasizes backend invalidation, so the replay checks should hit the server, not just the browser’s local state.
Best Value
Choosing a revocation approach
The right design depends on how much latency the security requirement allows and how many validators must agree. The options below trade off differently:
| Approach | Revocation latency | Runtime cost | Main gap |
|---|---|---|---|
| Opaque session lookup on every request | Immediate once the write is visible to all nodes | A store lookup per request | Replication lag or stale caches |
| Token introspection by resource servers | Immediate at the authorization server, subject to any local caching | A network call or cache per token check | Depends on the authorization server remaining reachable |
| Short-lived self-contained access tokens plus refresh-token revocation | Bounded by the access-token lifetime | Local validation, with more frequent refresh calls | Tokens remain valid until expiry |
| Terminated-token list | Immediate once every validator reads the list | A lookup per token check | List must be kept current on every validator |
| Per-user cutoff timestamp | Immediate once every validator reads the cutoff | A per-user lookup per token check | Cached cutoffs delay enforcement |
| Per-user signing key rotation | Immediate once new keys are distributed | Key distribution and rotation process | Key propagation and rotation behavior must be understood |
Compare each approach on revocation latency, coverage across browser, mobile, API, and federated clients, the cost of server-side lookups and their availability, cache and replication consistency, behavior during signing-key rotation, and the user impact of revoking legitimate sessions.
Troubleshooting when an old session still works
| Symptom | Likely cause | Fix |
|---|---|---|
| Old cookie still loads the dashboard | Session record was not revoked, or the write did not complete before the response | Revoke or delete the record atomically, and confirm the write before returning success |
| Old session works on some servers but not others | Replication lag, or an in-memory store on one node | Move session state to a shared store, and purge or shorten local caches |
| An API accepts an old access token after logout-all | The token is self-contained and validated locally with no termination check | Add a terminated-token list or per-user cutoff, or shorten the access-token lifetime |
| New access tokens keep appearing | The refresh token or its token family was not revoked | Call the revocation endpoint for the refresh token, and confirm the grant is revoked |
| User is signed back in without a password | Identity-provider session or remember-me record is still active | End the provider session where applicable, and revoke all persistent login records |
| Old credentials survive a password or MFA change | Factor changes do not trigger session termination | Terminate sessions and revoke grants when authentication factors change |
| Users are logged out of devices they did not intend to end | The action is broader than the interface describes | State the scope clearly, and offer per-device termination alongside logout-all |
What the standards establish and what they leave to implementers
NIST SP 800-63B-4 is the normative reference for session secrets and cookie handling. RFC 7009 defines revocation semantics for OAuth tokens, and RFC 9700 describes current OAuth practice, including refresh-token rotation and revocation after security events. OWASP ASVS 5.0 provides an application verification checklist, and the OWASP Web Security Testing Guide provides test cases for logout. None of these specifies how a particular product must propagate revocation across its own services, so the cross-service behavior remains an implementation decision that has to be verified in the deployed system.
Before giving product-specific steps, check the current OWASP pages and the documentation of the identity provider you use, because provider behavior for sessions, refresh tokens, and logout varies.
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.
