What is the biggest drawback of JWT?
The biggest drawback of JWT is the lack of built-in, efficient revocation — once a valid token is issued, it remains valid until its expiration time, even if the user logs out or their permissions change.
JWTs are stateless by design: the server does not store session information. While this improves scalability, it creates a critical revocation problem. Unlike traditional session cookies that can be instantly invalidated by deleting a server-side record, a JWT cannot be revoked without additional infrastructure (e.g., a token blacklist or a short expiration time). If a JWT is stolen, an attacker can use it until it expires, and if the user logs out, the token remains active. This forces developers to either accept the risk, use very short expiration times (which require frequent refreshes), or implement a stateful revocation store — undermining the stateless advantage.
- 1
Token size: JWTs contain header, payload, and signature; they are typically larger than session IDs, increasing bandwidth usage.
- 2
Information leakage: JWT payload is base64url-encoded, not encrypted (unless using JWE). Sensitive data should never be stored in a JWT.
- 3
Algorithm confusion attacks: Misconfigured servers accepting 'none' algorithm or type confusion (RS256 vs HS256) can lead to token forgery.
- 4
Clock skew issues: Expiration validation relies on correct server and client time synchronization.
- 5
Limited payload size: JWTs are often transmitted in HTTP headers, which have size limits (e.g., 8KB for many servers).
Despite these drawbacks, JWTs are widely used for short-lived access tokens in OAuth2/OIDC flows where revocation is handled via refresh token rotation and short expiration (e.g., 5–15 minutes). For long-lived sessions requiring immediate logout, traditional server-side sessions or token blacklists are more appropriate.
Scenario Questions
- 1
You need to add authentication to a small Node.js app using JWTs. If the token never expires, what could go wrong when a user logs out?
- 2
A junior teammate puts many user permissions into the JWT payload, making the token large. What impact might that have on the app?
- 3
How would you explain to a teammate why simply deleting a JWT on the client doesn’t guarantee the user can’t reuse it?
- 1
Our API uses JWTs, but after a user changes their password they can still access protected endpoints. Why is that happening?
- 2
During a security audit we discovered we have no way to revoke a compromised JWT. What options do we have to address this?
- 3
We’re seeing higher latency on auth checks because each request validates a large JWT. What are the root causes and how would you improve it?
- 1
Design a token revocation mechanism for a microservices platform that currently relies on stateless JWTs. What trade‑offs does your design involve?
- 2
If we need immediate logout across all of a user’s devices, how would you modify our JWT strategy to support that?
- 3
Discuss how JWT size affects network bandwidth and caching in a high‑traffic system, and propose ways to mitigate any negative effects.
- 1
We are migrating several legacy services from session‑based auth to JWTs. How would you handle revocation and backward compatibility at scale?
- 2
At an organization‑wide level, what policies would you establish for JWT lifecycle management, key rotation, and revocation to keep the system secure?
- 3
Explain how you would architect a centralized token blacklist service that works with distributed services while preserving the benefits of JWT statelessness.
Follow-up Questions
- ❓What strategies can you use to mitigate the revocation problem?
- ❓How would you decide between short‑lived JWTs and refresh tokens?
- ❓What are the trade‑offs of storing more claims in the token payload?