Token Revocation
Token revocation invalidates a grant before it expires, cutting off compromised sessions and ensuring logout actually ends access across clients and services.
Definition
Token revocation is the process of marking an issued token or grant as no longer valid at the authorization server, so refresh tokens stop working and, where supported, access tokens are rejected before their natural expiry.
Context and scope
Use it on logout, password change, device loss, suspected compromise, and role removal, especially for long-lived refresh tokens and offline access.
Common misconceptions
- Deleting a token from the client is revocation; the server must also invalidate it
- Revoking a refresh token instantly kills every access token; self-contained access tokens may remain valid
- Short access-token lifetimes make revocation unnecessary; refresh tokens can still live for months
Anti-patterns
- Implementing logout as a client-side redirect with no server-side invalidation
- Keeping a denylist that grows forever because entries are never expired
- Revoking only the current access token while leaving sibling refresh tokens active
Related concepts
Related examples
Authoritative source
Revocation is state
A signed token is valid because its signature and claims check out, not because the server remembers issuing it. Revocation reintroduces state: a record that a particular grant must no longer be honored. The design question is where that state lives and how quickly every verifier sees it.
How it works
RFC 7009 defines a revocation endpoint. The client sends POST /revoke with token=... and an optional token_type_hint, authenticated as the client that owns the token. The server invalidates the refresh token and, per policy, the access tokens derived from it. The endpoint returns 200 even for unknown tokens so it cannot be used to probe their existence.
For self-contained access tokens, early revocation requires a denylist keyed by jti, a per-user token version claim checked on each request, or introspection. Denylist entries only need to live until the token’s exp, which keeps the list bounded.
When to use it
Revoke on logout when the product promises server-side sign-out, on password or email change, when a device is reported lost, when an employee leaves, and whenever a refresh token may have leaked. Also revoke the whole grant family during refresh-token rotation if reuse is detected.
Trade-offs
State adds a lookup on the hot path and a coordination problem across regions. Denylists are simple but must be replicated and expired correctly. Token versioning invalidates all sessions for a user, which is secure but disruptive. Purely local JWT validation cannot see revocation, so the token lifetime becomes the revocation window.
Example and misconceptions
A user logs out on a shared laptop. The client deletes its tokens, but the refresh token was already copied. Without a server-side revocation call, the attacker keeps minting access tokens. Calling /revoke and invalidating the grant family ends the session everywhere.
The common misconception is that revocation is instantaneous for every token type. It is immediate for refresh tokens and introspection-checked tokens, but bounded by expiry for locally validated JWTs.
Related concepts: Token Introspection, JSON Web Token (JWT), and Session vs Token Authentication.