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

What JWT Actually Is

JWT (JSON Web Token) is a three‑part string separated by dots: Header, Payload, and Signature.

Header : declares the algorithm (e.g., HS256).

Payload : contains user data such as user ID, roles, and expiration. It is only Base64‑encoded, not encrypted, so anyone can decode it.

Signature : computed from Header, Payload, and a server secret to prevent tampering.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Authentication flow: user logs in → server issues a token → client stores it (commonly 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 essence of “stateless”.

Statelessness Cost: Four Critical Scenarios

Compromised account: a token with a 2‑hour lifespan cannot be revoked immediately.

Ban a user: the existing token remains usable.

Password change: other devices stay logged in because the token is still valid.

Form submission timeout: a long‑running form may lose its data if the token expires mid‑process.

Why Put Tokens in Redis

To address the above problems, the simplest solution is a blacklist: when a user is forced offline, add the token to a blacklist and reject any request that finds the token there. Redis is ideal for the blacklist because it offers sub‑millisecond lookups and shared state across multiple servers, unlike in‑memory storage (non‑shared) or a database (slow).

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

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

Redis only stores “invalid” tokens, so write operations are rare while reads are fast.

A more aggressive approach is to store every token in Redis (a white‑list), turning JWT into a session ID that is looked up on each request.

Blacklist vs White‑list: Core Differences

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

JWT + Blacklist : stores only invalid tokens, performs one Redis lookup per request, can actively revoke, is not fully stateless.

Token in Redis (White‑list) : stores all tokens, performs one Redis lookup per request, can actively revoke, loses statelessness.

Blacklist is lightweight—normal requests don’t write to Redis, only revocation does—so most projects choose it. White‑list offers stronger control (e.g., limiting concurrent sessions, real‑time online status) but incurs a Redis lookup on every request.

Double‑Token Refresh Strategy

Use a short‑lived AccessToken (≈30 minutes) for actual authorization and a long‑lived RefreshToken (≈7 days) solely to obtain new AccessTokens. When the AccessToken expires, the front‑end silently exchanges the RefreshToken for a fresh AccessToken. Storing the RefreshToken in Redis allows immediate revocation after a password change.

Redis Reliability

Redis provides mature high‑availability solutions:

Sentinel : automatically promotes a replica when the master fails.

Cluster : shards data across nodes for horizontal scaling.

Single‑node query latency is typically under 1 ms, and a single instance can handle tens of thousands of QPS, disproving the “single‑point‑of‑failure” myth.

Interviewers’ Mocking Points

First case: using JWT but bypassing signature verification and checking Redis for token existence on every request. This reduces JWT to a random string session ID, wasting the token’s built‑in capabilities.

Second case: needing active revocation, choosing JWT + Redis, but only stating “store token in Redis” without explaining the underlying requirement. The interviewer assumes a lack of understanding of stateless design.

When Pure JWT Is Actually Appropriate

Cross‑service calls: a gateway verifies the token once and downstream services trust the embedded user ID.

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

Low‑security internal tools: few users, no need for forced logout.