Why Storing JWT Tokens in Redis Isn’t a Flaw – When and How to Do It

Interview Context

During a technical interview, candidates are often mocked for storing tokens in Redis; the interviewer assumes the candidate misunderstands JWT’s stateless nature.

Token Storage Options

Traditional cookie/session : The server generates a random session ID and stores it in a shared store such as Redis or MySQL. Storing the raw token is acceptable, but if the database leaks, an attacker could impersonate users. A common mitigation is to store only a hash of the token.

JWT : Offers a stateless solution where the token itself contains user information and a signature, eliminating the need for server‑side storage. However, JWTs lack a built‑in revocation list, making immediate invalidation impossible without additional mechanisms.

Why Redis May Be Needed

Business requirements often demand the ability to forcibly log out users, enforce password‑change invalidation, or ban accounts. Implementing a central store (e.g., Redis) enables:

Blacklist of revoked tokens.

Sliding expiration by refreshing TTL on each request.

One‑click kick‑out and multi‑device login limits.

Redis also supports high‑performance lookups (sub‑millisecond latency) and can be made highly available with Sentinel or Cluster.

Security Risks of Redis

Potential issues include weak passwords, exposing Redis to the public internet, insufficient firewall rules, and reliance on internal network security. Real‑world incidents show that misconfigured Redis can lead to server compromise or mining attacks.

Practical Implementation

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 code adds a token to a Redis‑based blacklist with a TTL matching the token’s remaining lifetime and checks the blacklist on each request.

When JWT’s Statelessness Truly Shines

In micro‑service architectures, JWTs allow the gateway to verify the signature once and propagate user identity downstream without additional lookups. They also excel for one‑time credentials such as email verification links or password‑reset tokens.

Conversely, if a system needs immediate revocation, multi‑device session control, or frequent token renewal, storing token identifiers (or a blacklist) in Redis becomes necessary, effectively turning the solution into a stateful session manager.

Decision Guidance

Choose Redis‑backed storage when the business requires active session control, blacklist capabilities, or sliding expiration. If the application only needs simple login‑once‑expire‑later behavior, a pure JWT approach avoids the extra Redis dependency.