JWT revocation strategies: blocklist and short TTL tradeoffs

JWT Revocation Strategies

JWTs are stateless — the server stores nothing. So how do you invalidate one before it expires? This is the hardest JWT problem.

Option 1: Short TTL + accept the gap. Use 5–15 minute access tokens. A stolen token is valid for at most 15 minutes. For most apps, this risk is acceptable. Pair with refresh token rotation so logout invalidates the refresh token, stopping new access tokens from being issued.

Option 2: Token blocklist. Store revoked token IDs (the jti claim) in Redis with a TTL matching the token's remaining lifetime. On every request, check the blocklist.

// Add jti when signing
const token = jwt.sign(
  { sub: user.id, jti: crypto.randomUUID() },
  SECRET,
  { expiresIn: '1h' }
);

// In verify middleware
const payload = jwt.verify(token, SECRET, { algorithms: ['HS256'] });
const revoked = await redis.get(`blocklist:${payload.jti}`);
if (revoked) return res.status(401).json({ error: 'Token revoked' });

// On logout
await redis.set(`blocklist:${payload.jti}`, '1', 'EX', remainingTTL);

The blocklist approach reintroduces state — you now depend on Redis. At that point, you are essentially doing sessions with JWT syntax. This is fine if revocation is required, but understand the architectural cost before choosing it.