Why Interviewers Mock Storing Tokens in Redis—and How to Answer

What is JWT

JWT (JSON Web Token) is a three‑part string separated by dots: Header, Payload, and Signature. The Header declares the algorithm (e.g., HS256), the Payload carries user data (ID, roles, expiration) and is only Base64‑encoded—not encrypted—so anyone with the token can decode it. The Signature is generated from Header + Payload + a server secret to prevent tampering.

The full verification flow is: user logs in → server issues a token → client stores it (usually in localStorage) → each request includes Authorization: Bearer <token> → server verifies the signature and extracts user info. No database or Redis lookup is required, which is the meaning of “stateless”.

The cost of "stateless" JWT: four fatal scenarios

Account compromised: a token with a 2‑hour lifetime cannot be revoked immediately; it remains valid until expiration.

User banned: the existing token continues to work.

Password change: other devices keep using the old token.

Form submission timeout: a long‑running form may be lost if the token expires before the user clicks submit.

These situations are common in real‑world business systems.

Why store tokens in Redis

To solve the above problems the most direct solution is a blacklist: when a user is forced offline, add the token to a blacklist and reject requests that find the token there. The blacklist must be stored where lookups are fast and shared across instances—Redis fits because a miss costs <1 ms and it is distributed.

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);
}

Redis only stores the “invalid” tokens, so normal requests rarely write to it and reads are sub‑millisecond.

A more thorough approach is to store every token in Redis (a whitelist) and check Redis on each request, which is essentially a session store that uses the JWT format as the session ID.

Blacklist vs. Whitelist: core differences

Pure JWT : stores nothing, 0 Redis lookups, cannot revoke, remains stateless.

JWT + Blacklist : stores only revoked tokens, 1 Redis lookup per request, can revoke, partially breaks statelessness.

Token stored in Redis (Whitelist) : stores all tokens, 1 Redis lookup per request, can revoke, not stateless.

Blacklists are lightweight and preferred when revocation is occasional; whitelists give stronger control (e.g., limiting concurrent sessions) but add a Redis dependency to every request.

Dual‑token renewal scheme

Use a short‑lived AccessToken (≈30 minutes) for actual authentication and a long‑lived RefreshToken (≈7 days) solely to obtain new AccessTokens. Store the RefreshToken in Redis so that a password change can delete it, forcing the user to re‑login.

Is Redis reliable?

Redis has been used in production for over a decade with high‑availability setups such as Sentinel (automatic master failover) and Cluster (sharding and horizontal scaling). A single query typically finishes within 1 ms and a single node can handle tens of thousands of QPS, disproving the “single‑point‑of‑failure” argument.

What the interviewer is really mocking

Two cases:

You use JWT but bypass its signature verification and check Redis for every request. This merely uses the JWT format as a random string and wastes the stateless benefit.

You need active revocation and chose a JWT+Redis solution, but you only said “store the token in Redis” without explaining the rationale, leading the interviewer to think you don’t understand stateless design.

In the first case you should switch to a pure session approach; in the second you must articulate the business requirements that justify revocation.

How to answer in an interview

Do not start with “store the token in Redis” or “JWT is stateless”. First describe the business needs: whether you must be able to kick a user offline, invalidate other devices after a password change, or limit concurrent sessions. Then choose the appropriate scheme:

If revocation is required, propose JWT + Redis blacklist and explain that pure JWT cannot actively revoke tokens.

If revocation is unnecessary, stick with pure JWT and describe the signature verification flow and key management.

The key point the interviewer wants is that you understand the boundaries of each approach, not just the choice itself.