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

Interview scenario and the misunderstanding

During a job interview you mentioned storing the authentication token in Redis, and the interviewer laughed, saying you didn’t understand JWT’s stateless design. The article clarifies that the problem is not the choice of Redis but the failure to explain why it is needed.

What JWT is

JWT (JSON Web Token) is a three‑part string: Header (algorithm, e.g., HS256), Payload (user data such as ID, role, expiration – only Base64‑encoded, not encrypted), and Signature (Header + Payload signed with a server secret). Example token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Verification consists of decoding the three parts, checking the signature, and extracting user info—all without consulting a database or Redis, which is the essence of “stateless”.

Problems with pure stateless JWT

Because a JWT remains valid until its expiration, several real‑world scenarios become painful:

**Password theft** – an attacker can use a still‑valid token even after the user changes the password.

**User ban** – a blocked account can continue to act while its token is alive.

**Password change** – other devices stay logged in until the token expires.

**Form submission timeout** – a long‑running form may be rejected if the token expires mid‑process.

These cases require a way to revoke tokens before their natural expiry.

Why put tokens in Redis – blacklist approach

The simplest remedy is a blacklist: when a token must be invalidated, add its identifier to Redis. Each request first checks the blacklist; if present, the request is rejected.

// Logout – add token to blacklist
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);
    }
}

// Validation – reject if blacklisted
public boolean isTokenValid(String token) {
    if (redisTemplate.hasKey("blacklist:" + token)) {
        return false; // token is blacklisted
    }
    return jwtUtil.verify(token); // normal signature verification
}

This stores only “invalidated” tokens, so write traffic is low and lookups are sub‑millisecond.

Whitelist (token‑in‑Redis) approach

A more aggressive solution stores every issued token in Redis (a white‑list). Validation always queries Redis, making the system stateful but allowing immediate revocation, concurrent‑session limits, and real‑time online‑user tracking.

Comparison of three schemes

Pure JWT : stores nothing, 0 Redis queries, cannot revoke, fully stateless.

JWT + blacklist : stores only revoked tokens, 1 Redis query per request, can revoke, partially stateful.

Token‑in‑Redis (white‑list) : stores all tokens, 1 Redis query per request, can revoke, not stateless.

Blacklist is lightweight and fits most business needs; whitelist offers stronger control at the cost of a Redis hit on every request.

Token renewal – double‑token design

To avoid long‑lived access tokens, use two tokens:

AccessToken – short‑lived (e.g., 30 minutes) for actual authorization.

RefreshToken – long‑lived (e.g., 7 days) used only to obtain a new AccessToken.

When the AccessToken expires, the client silently exchanges the RefreshToken for a new AccessToken. If active revocation is required (e.g., after a password change), store RefreshTokens in Redis and delete them on demand.

Is Redis reliable?

Redis offers high‑availability via Sentinel (automatic master failover) and Cluster (sharding and horizontal scaling). Single‑node queries are typically <1 ms, and a single instance can handle hundreds of thousands of QPS, so Redis is not a bottleneck nor a single point of failure when HA is configured.

What the interviewer was really mocking

Two possible reasons:

You used the JWT format but performed all validation against Redis, effectively turning JWT into a random session ID – a misuse of the tool.

You chose a legitimate JWT + Redis blacklist solution but failed to explain the business need for revocation, making it seem like you didn’t grasp JWT’s stateless intent.

In the first case the design should be replaced by a plain session ID; in the second case you must articulate the requirement that drives the Redis addition.

When pure JWT is actually suitable

Cross‑service calls – the gateway verifies the JWT once and downstream services read the user ID directly from the token.

One‑time credentials – email verification links, password‑reset links, temporary share URLs.

Low‑security internal tools – small‑scale utilities where kicking users out is unnecessary.

How to answer in an interview

Don’t start with “I store the token in Redis” or “I use a stateless JWT”. First, describe the business requirements (need for immediate revocation, multi‑device limits, etc.). Then choose the appropriate scheme and explain why:

If revocation is needed, propose JWT + Redis blacklist or full Redis whitelist, emphasizing that Redis is introduced to meet the requirement, not arbitrarily.

If revocation is unnecessary, stick to pure JWT and detail the signature verification flow, expiration handling, and key management.

The interviewer wants to see that you understand the trade‑offs and can justify the design, not just the final choice.

Conclusion

JWT’s stateless advantage is the lack of server‑side storage, which simplifies cross‑service identity propagation. However, the inability to revoke tokens forces many systems to add an external store such as Redis. A blacklist stored in Redis is a lightweight compromise; a whitelist gives full control at the cost of a Redis lookup on every request. Double‑token renewal solves the short‑lived access‑token problem, and Redis’s HA mechanisms make it a reliable choice. In interviews, always link the technical choice to concrete business needs and explain the pros and cons of each approach.