How do you revoke JWTs?
Revoke JWTs by introducing a stateful revocation layer using a token blacklist (JTI), user versioning, or short-lived tokens with refresh token rotation.
Because JWTs are stateless, they cannot be revoked directly. Practical revocation strategies involve adding a small stateful component. The most common methods are: (1) Token blacklist – store revoked token identifiers (JTI) in a fast cache like Redis; (2) User versioning – increment a version number in the user record and include it in the JWT; (3) Short-lived access tokens (5–15 minutes) with refresh token rotation – revoke the refresh token, forcing re-authentication. For massive scale, combine blacklist with versioning and short lifetimes to minimize the revocation window.
Scenario Questions
0-2 years experience
- 1We have a simple Node.js API that issues JWTs on login. When a user logs out, how would you make sure the token can’t be used again using Redis?
- 2If you store a JWT’s jti in Redis with a TTL equal to the token’s expiry, what happens if the Redis entry expires before the token does?
- 3How would you integrate a Redis blacklist check into a request‑handling middleware before accepting the JWT?
2-5 years experience
- 1Our service uses short‑lived JWTs and a Redis blacklist for revocation, but a bug caused some revoked tokens to still be accepted. Walk me through how you’d debug the issue.
- 2We need immediate revocation for password changes while keeping Redis memory usage low. What trade‑offs would you consider in your revocation design?
- 3If the system scales to 10 k requests per second, how would you ensure the Redis blacklist lookup doesn’t become a bottleneck?
5-8 years experience
- 1Design a revocation strategy that works across multiple microservices, each with its own Redis instance, while guaranteeing consistency.
- 2Explain how you would handle revoking JWTs when the Redis cluster experiences a network partition or node failure.
- 3What are the security implications if an attacker floods the revocation list with many entries, and how would you mitigate that risk?
8+ years experience
- 1Our company is moving from a pure JWT model to a hybrid system with refresh tokens stored in a database. How would you evolve the revocation mechanism to support both, ensuring backward compatibility?
- 2Across several product teams, some services use Redis and others use in‑memory caches for revocation. How would you standardize the revocation architecture while minimizing operational overhead?
- 3Compliance requires keeping token revocation logs for seven years. How would you design a solution that satisfies auditability without degrading runtime performance?
Follow-up Questions
- What would you do if the Redis instance becomes unavailable?
- How do you decide the TTL for a revocation entry?
- Are there any security concerns with a Redis‑based blacklist?