Why Storing Tokens in Redis Is the Right Answer in Interviews

Why interviewers mock token‑in‑Redis

Some interviewers assume a pure stateless JWT design, believing that storing tokens on the server is unnecessary, wastes Redis resources, and shows only theoretical knowledge.

Design considerations for storing tokens in Redis

Controllable logout and strong security – JWT cannot be revoked; changing a password, logging out, or blocking a user leaves the token valid until expiration. Deleting the token key in Redis invalidates the session immediately.

Support for multi‑device login, SSO and remote kick‑out – Managing session state on the server is required for these scenarios; a stateless JWT cannot enforce them.

Lightweight and high‑performance – The token is a short random string; Redis stores it as a simple key‑value pair with TTL, providing in‑memory speed and throughput orders of magnitude higher than database‑backed sessions.

Dynamic permission and role refresh – Permissions are kept outside the token payload; updating Redis changes a user’s rights without waiting for token expiration.

Scenario‑driven architecture – Pure stateless JWT fits simple use‑cases without logout requirements; enterprise‑grade systems with security controls benefit from stateful sessions backed by Redis.

Practical implementation

Generate a random string (e.g., UUID or nanoid) and use it as the token key.

Redis key pattern: login:token:{tokenStr} Value stores user ID, device information, permission tags, and expiration timestamp.

Set a TTL equal to the session duration so the key expires automatically.

Authentication interceptor extracts the token from the request, looks up the key in Redis, and grants access only when the key exists.

Comparison with pure JWT

Redis‑stored token

Advantages: controllable logout, strong security, multi‑device support.

Drawback: introduces a lightweight dependency on Redis, which is common in modern projects.

Pure stateless JWT

Advantages: no server‑side storage, simple implementation.

Drawback: cannot be revoked proactively, weaker security, difficult to manage business rules.

When Redis is not required

Public APIs that do not require authentication.

Simple internal tools without risk control or kick‑out needs.

One‑time temporary authorizations.

Advanced extensions (optional)

Enable Redis persistence or clustering to achieve high availability.

Apply bucket‑based rate limiting bound to token/device to mitigate abuse.

Adopt a double‑token scheme: accessToken (short‑TTL in Redis) + refreshToken to balance user experience and security.