Token revocation: do's and don'ts
Updated 2026-05-07
Token revocation is the operational counterpart to short-lived sessions. Together they form the bound on bearer-token theft impact: even if a token is stolen, it's either expired soon, rotated soon, or revocable on demand.
For the broader session-management context, see the session management guide and the OAuth/OIDC client config best-practice.
Do
Implement refresh token rotation with reuse detection
Each refresh issues a new refresh token; the old one is revoked. Detecting reuse of the rotated token signals replay attack, the system revokes the entire token chain. OAuth 2.1 requires this for non-confidential clients.
OAuth 2.1 specification mandates rotation or sender-constraining for non-confidential refresh tokens. Production deployments at major CIAM vendors have caught token theft specifically through reuse detection firing on stolen refresh tokens.
Keep access token lifetimes short (5–15 minutes)
Short access tokens bound the blast radius of bearer-token theft. JWT access tokens are not revocable mid-lifetime; the lifetime IS the revocation guarantee.
OWASP recommends access token lifetimes under one hour; OAuth 2.0 Security BCP recommends shorter for sensitive applications. The 2026 default of 5–15 minutes is the consensus.
Maintain a session table for refresh tokens with explicit revocation
Refresh tokens must be revocable on logout, on suspicious activity detection, and on admin-initiated session termination. Server-side session state is the only reliable mechanism.
Modern CIAM ship session-table-backed refresh tokens by default. Incidents where a stolen refresh token granted indefinite access have specifically traced to deployments that lacked server-side revocation.
Expose a revocation endpoint clients can call on logout
RFC 7009 defines the OAuth Token Revocation endpoint. Clients call it on logout to immediately invalidate the token rather than waiting for natural expiry.
RFC 7009 is the standard. Most modern CIAM expose the revocation endpoint; clients that don't call it on logout leave a window where the token still works after the user thinks they've signed out.
Don't
Don't rely on JWT expiry alone for security-critical revocation
A JWT is valid until expiry, there is no native revocation mechanism. Logout, factor change, and admin termination need a server-side check the JWT alone can't provide.
Multiple production incidents have traced to assumed JWT revocation that didn't exist. The fix pattern is the hybrid: short-lived JWT access tokens plus rotating opaque refresh tokens with server-side revocation.
Don't expose every active session in client-side UI without protection
A 'sessions list' page that shows all active tokens is a target for attackers who compromise one session, they harvest the token list and pivot.
OWASP guidance on session management. The pattern that works: the sessions list shows session IDs and metadata, never the tokens themselves; revocation is by ID and requires step-up auth.
Don't share the same refresh token across multiple clients
Refresh tokens should be per-client. A token shared across clients can't be cleanly revoked when one client is compromised.
OAuth 2.1 specification requires per-client refresh tokens. Modern CIAM ship per-client tokens by default; the antipattern surfaces in custom-built auth where developers reused tokens for convenience.
Don't skip revocation on factor changes
When a user changes password, MFA factor, or recovery email, all existing sessions should be re-evaluated or terminated. Not doing so means an attacker who already compromised a session keeps it after the user detects and changes credentials.
OWASP Authentication Cheat Sheet and broadly accepted best practice. The pattern: factor change triggers session termination plus notification, requiring re-authentication.