Why JWT Is Unsuitable for Session Management and Its Security Risks

Hello everyone, I am Chen (the author). This article will thoroughly explain why JSON Web Tokens (JWT) are not suitable for storing sessions and the security risks they introduce.

1. Clarifications

Many people mistakenly compare cookies and JWTs, which is like comparing memory and disk. Cookies are a storage mechanism, while JWTs are signed tokens. The proper comparison is Session vs. JWT and Cookies vs. Local Storage.

2. Commonly Claimed Advantages of JWT

When promoting JWTs, people often cite the following benefits:

Easy horizontal scaling

Easy to use

More flexible

More secure

Built‑in expiration

No need to ask users about cookie usage

Prevents CSRF attacks

Better for mobile clients

Works when users block cookies

Below each claim is examined and shown to be misleading or incorrect.

Easy horizontal scaling? This only holds for stateless JWTs, which few projects actually need. Traditional stateful sessions with Redis provide far simpler scaling across single or multiple servers.

Easy to use? In reality you must implement session management yourself, whereas standard session cookies work out‑of‑the‑box.

More flexible? No concrete examples demonstrate greater flexibility; mainstream session implementations already allow storing arbitrary data.

More secure? Signed cookies are just as secure as signed JWTs. Encryption alone does not guarantee safety; misuse can even reduce security.

Built‑in expiration? Server‑side expiration is more controllable; JWT expiration cannot be revoked before the token expires.

No need to ask users about cookies? Legal requirements apply to any persistent identifier, not just cookies.

Prevents CSRF attacks? Storing JWTs in cookies still requires CSRF protection; storing them elsewhere (e.g., Local Storage) introduces XSS risks.

Better for mobile? Modern browsers and mobile HTTP clients fully support cookies and sessions.

Works when users block cookies? Users who block persistence typically block all mechanisms, making JWTs ineffective.

3. Disadvantages of Using JWT for Sessions

Using JWTs as a session mechanism introduces several serious drawbacks:

Increased payload size : Stateless JWTs embed all session data, quickly exceeding cookie or URL length limits.

Reduced security : Storing JWTs in places other than cookies (e.g., Local Storage) exposes them to XSS attacks.

Cannot be individually revoked : Stateless tokens remain valid until expiration, preventing immediate logout or password‑change invalidation.

Stale data : Information inside a token may become outdated, leading to authorization inconsistencies.

Lack of production‑grade libraries : Stateful JWT implementations lack the extensive real‑world validation that mature session libraries (e.g., express‑session) have.

4. Conclusion

Stateless JWTs cannot be individually destroyed or updated and may cause size and security issues. Stateful JWTs behave similarly to session cookies but lack widespread production validation and client support. Unless you operate at massive scale, using JWTs for session management is unnecessary—stick with traditional sessions.

5. Appropriate Use Cases for JWT

While unsuitable for persistent sessions, JWTs excel as short‑lived, one‑time authorization tokens. For example, a file‑service can issue a temporary download token that the client presents to a separate download server.

Key characteristics of such usage:

Tokens have a very short lifespan (minutes).

Each token is used only once.

The main application continues to use regular sessions; only the download service relies on JWTs.

Thus, combining sessions and JWTs can be sensible when each serves its proper purpose.

JSON Web Token (JWT) is a compact, URL‑safe means of representing claims to be transferred between two parties. [...] enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

Reference:

https://tools.ietf.org/html/rfc7519