Token Revocation: Strategies for Invalidating Compromised Tokens

One of the most significant challenges in token-based authentication is revocation - the ability to invalidate a token before it naturally expires. This is critical when a user logs out, changes their password, or when a token is suspected to be compromised.

The Statelessness Challenge

JWT tokens are designed to be stateless - the server validates them using only the signature, without querying a database. This is excellent for performance and scalability but makes revocation inherently difficult. Once issued, a JWT remains valid until its expiration time unless the server takes additional measures.

Blacklisting (Token Deny List)

Maintain a database or cache (Redis) of revoked token identifiers (the jti claim). On each request, check if the token's jti is in the blacklist. This adds a database lookup to every request but provides immediate revocation capability. Use short access token lifetimes (15 minutes) to keep the blacklist small.

Versioning

Include a token version number in the JWT payload. Maintain a current version per user in the database. When revocation is needed, increment the version. Any token with an older version is rejected. This approach requires only one database query per user, not per token.

Event-Driven Revocation

In microservice architectures, use a pub/sub system (Redis Pub/Sub, Kafka, WebSocket) to broadcast revocation events. When a token is revoked, publish the event, and all services update their local cache. This provides near-real-time revocation across distributed systems.

Short-Lived Tokens + Refresh Token Rotation

The most practical approach combines short-lived access tokens (5-15 minutes) with rotating refresh tokens. Access tokens expire quickly, limiting the damage window. Refresh tokens can be revoked by invalidating them in the database. When a refresh token is used, both the old and new tokens are rotated, detecting reuse attacks.

Revocation for Different Scenarios

• User Logout: Revoke the associated refresh token and clear cookies
• Password Change: Invalidate all user tokens by incrementing version
• Admin Suspension: Add user to a deny list checked on every request
• Security Incident: Rotate signing keys and invalidate all tokens

Conclusion

Effective token revocation requires balancing security with performance. The combination of short-lived tokens, refresh token rotation, and version-based invalidation provides a practical and secure approach for most applications.