Why Developers Are Abandoning JWT for Authentication and Authorization

JWT Advantages

Compared with session‑based authentication, JWT offers four main benefits:

Stateless

All required authentication data is embedded in the token, so the server does not need to store session state, improving scalability. However, this statelessness makes revocation difficult: a token cannot be invalidated before its expiration, and logout does not immediately invalidate the token.

Prevents CSRF Attacks

Because JWTs are typically stored in localStorage and sent in an Authorization header, they are not automatically included in cross‑site requests that rely on cookies, thus avoiding CSRF vulnerabilities.

Suitable for Mobile Apps

Session authentication depends on cookies and server‑side state, which is inconvenient for mobile clients. JWTs can be stored locally on any platform and are language‑agnostic.

Friendly to Single Sign‑On

Since the token resides on the client, SSO implementations avoid the cross‑domain cookie issues that arise with session IDs.

Common JWT Problems and Mitigations

Token Revocation (Logout, Password Change, etc.)

Scenarios such as logout, password change, role modification, account deletion, or forced logout require immediate token invalidation, which JWT does not provide out of the box.

Four practical solutions are summarized:

Store JWT in a database (e.g., Redis) – Delete the token to revoke it, at the cost of extra lookups and breaking statelessness.

Blacklist mechanism – Keep a Redis set of revoked tokens and check each request against it.

Rotate secret per user – Change the user's signing secret to invalidate existing tokens, but this adds complexity in distributed environments.

Short‑lived tokens with frequent rotation – Reduce the token lifespan, requiring users to re‑authenticate more often.

A useful variant is to sign the JWT with a hash of the user's password; changing the password automatically invalidates previous tokens.

Token Renewal

Because JWTs are often short‑lived, a renewal strategy is needed. Four approaches are discussed:

Session‑like renewal (not recommended): server issues a new token when the current one is near expiry.

Return a new token on every request (not recommended): high overhead.

Set token expiry to midnight (not recommended): only suitable for low‑security scenarios.

Use a pair of tokens (recommended) : an accessJWT (short‑lived) and a refreshJWT (long‑lived). The client stores both; when the access token expires, it presents the refresh token to obtain a new access token.

The dual‑token scheme has trade‑offs: it requires client cooperation, must invalidate both tokens on logout, may experience brief gaps during refresh, and the refresh token must be protected because possession grants new access tokens.

Token Size

JWTs consist of a Base64Url‑encoded header, payload, and signature, making them larger than simple opaque tokens and increasing network overhead.

Mitigation strategies include:

Minimize payload data to only essential user and permission information.

Compress the token (e.g., GZIP) before transmission.

Use traditional opaque tokens stored server‑side (e.g., in Redis) when size is a concern.

Example JWT structure and a sample token are shown below:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Summary

JWT’s stateless nature is a key advantage, but practical use often requires auxiliary mechanisms to handle revocation, refresh, and size concerns. Choosing between JWT and session‑based authentication should depend on specific project requirements; neither approach is universally superior.

In some cases, a simple opaque token backed by Redis can be a viable alternative to JWT.