Why Using JWT for Sessions Is a Bad Idea and Safer Alternatives

1. First Clarification

Many people mistakenly compare cookies and JWTs, which is as meaningless as 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 Promoted "Advantages" of JWT

Easy horizontal scalability

Easy to use

More flexible

More secure

Built‑in expiration

No need to ask users about cookies

Prevents CSRF attacks

Better for mobile

Works when cookies are blocked

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

Easy horizontal scalability? Only true for truly stateless JWTs, which few projects need. Traditional stateful sessions can be scaled with a shared Redis store without any special handling.

Easy to use? In practice you must implement token issuance, storage, renewal, and revocation yourself, whereas standard session cookies work out‑of‑the‑box in most frameworks.

More flexible? No concrete examples demonstrate superior flexibility; regular sessions already allow arbitrary data storage.

More secure? Signed cookies provide comparable security. Encryption does not automatically make a system safer, and storing JWTs in places other than cookies (e.g., Local Storage) introduces XSS‑related risks.

Built‑in expiration? Server‑side session stores also support expiration, and stateless JWT expiration cannot be revoked early, leading to stale or over‑privileged tokens.

No need to ask users about cookies? Data‑protection regulations apply to any persistent identifier, not just cookies.

Prevents CSRF? Storing JWTs in cookies still requires CSRF protection; storing them elsewhere avoids CSRF but opens XSS vulnerabilities. Proper CSRF tokens are the correct mitigation.

Better for mobile? Modern browsers and mobile frameworks fully support cookies and sessions, so there is no advantage.

Works when cookies are blocked? Users who block persistent storage typically block all mechanisms (cookies, Local Storage, etc.), making JWTs ineffective.

3. Disadvantages of Using JWT as a Session Mechanism

More space‑consuming – JWTs embed all session data, quickly exceeding cookie size limits.

Less secure when stored client‑side – Tokens in Local Storage are accessible to any injected JavaScript, exposing them to XSS attacks.

Cannot be individually revoked – Stateless tokens remain valid until expiration, preventing immediate logout or credential revocation.

Data staleness – Information inside a token may become outdated, e.g., revoked admin rights, because the token cannot be invalidated.

Lack of production‑validated libraries – Mature session libraries (e.g., express‑session) have years of battle‑tested security, whereas JWT‑based session solutions are far less proven.

4. Conclusion

Stateless JWTs cannot be revoked or updated individually and introduce size and security concerns. Stateful JWTs behave like regular session cookies but lack extensive production validation and client‑side support. Unless you operate at massive scale, using standard sessions is simpler and safer.

5. When JWTs Are Appropriate

JWTs shine as short‑lived, single‑use authorization tokens. For example, a file‑download service can issue a one‑time JWT that allows a client to fetch a file from a separate, stateless download server.

Key characteristics of this use case:

Very short lifetime (minutes)

Single use per request

Server still uses sessions for other interactions

Thus, combining sessions and JWTs is valid when each serves its own purpose, but JWTs should never be used as a persistent session store.

Reference: JSON Web Token specification ( https://tools.ietf.org/html/rfc7519) defines JWT as a compact, URL‑safe means of representing claims that can be digitally signed or encrypted.