Why Storing JWTs in Redis Sparks Interview Controversy—and When It Makes Sense

An interview question asked why a candidate would store authentication tokens in Redis and how to respond to the interviewer's criticism.

Key Points from Multiple Experts

1. Security Checklist : Review code reviews, gray‑release, blue‑green deployment, regular penetration testing, network isolation, access control, encrypted password fields, and data masking. Missing any of these may indicate a weak security posture.

2. Token Storage Options :

Traditional cookie/session : Server generates a random session ID stored in Redis or MySQL. Simple but vulnerable if the database leaks; storing a hash of the token mitigates this.

JWT : Stateless, no server‑side storage needed. However, revoking a compromised token is difficult; you may need to store token IDs or a blacklist in Redis.

3. Why Use Redis :

Allows forced logout, single‑device login, password‑change invalidation, and blacklisting.

Enables sliding expiration by refreshing TTL on each request, avoiding short‑lived token expiry issues.

Provides a central place for blacklists, which pure JWT cannot offer.

4. Interview‑Style Responses :

"JWT is stateless, but our business requires active session management such as forced logout and device limits, so we store token identifiers in Redis to enforce these policies without sacrificing the benefits of JWT for downstream services."

Additional concerns discussed include:

Performance impact of Redis is minimal (sub‑millisecond latency) compared to RSA signature verification.

Redis high availability via Sentinel or Cluster eliminates single‑point‑of‑failure worries.

Using JWT purely for one‑time credentials (email verification, password reset) is ideal.

Implementation Example

The following Java code demonstrates a simple blacklist stored in Redis:

public void logout(String token) {
    long expiration = jwtUtil.getExpiration(token);
    long ttl = expiration - System.currentTimeMillis();
    if (ttl > 0) {
        redisTemplate.opsForValue().set("blacklist:" + token, "1", ttl, TimeUnit.MILLISECONDS);
    }
}

public boolean isTokenValid(String token) {
    if (redisTemplate.hasKey("blacklist:" + token)) {
        return false;
    }
    return jwtUtil.verify(token);
}

This approach turns a stateless JWT into a controllable session by checking the blacklist on each request.

Conclusion: Whether to store tokens in Redis depends on business requirements. If you need immediate revocation, multi‑device control, or sliding expiration, Redis is appropriate. If the system only needs simple login‑logout without such controls, a pure JWT solution avoids extra infrastructure.