Why Many Developers Avoid Using JWT: Risks and Drawbacks Explained

What Is JWT?

JSON Web Token (JWT) is a compact, URL‑safe representation of a set of claims. A JWT consists of three Base64Url‑encoded parts separated by dots: header , payload , and signature . The header declares the signing algorithm (e.g., HS256 for HMAC‑SHA256 or RS256 for RSA‑SHA256). The payload carries claims such as sub (subject), exp (expiration), iat (issued‑at), and custom fields like username or roles. The signature is computed over header.payload using the selected algorithm and a secret key or private key, allowing the receiver to verify integrity and authenticity.

Typical JWT Workflow

Client submits credentials (e.g., username/password) to the authentication endpoint.

Server validates the credentials and creates a JWT containing the required claims.

Server signs the token with a secret (HMAC) or private key (RSA/ECDSA) and returns it to the client, usually in the response body or as a Set‑Cookie.

Client stores the token (commonly in memory, localStorage, or an HttpOnly cookie) and includes it in subsequent requests, typically in the Authorization: Bearer <token> header.

Each protected endpoint extracts the token, verifies the signature, checks expiration and other validation rules, and then uses the claims to enforce authorization.

Why JWT Can Be Problematic

Size Overhead

A JWT is considerably larger than a simple session identifier. For example, a 5‑byte user ID stored in a cookie becomes a token of roughly 250 bytes after Base64Url encoding and signing—about 50× larger—adding bandwidth and storage costs.

Redundant Signatures

Many web frameworks already provide signed (and optionally encrypted) session cookies. Adding a JWT on top of such a cookie creates a double‑signature scenario without additional security benefits.

Token Revocation

Because a JWT is self‑contained and remains valid until its exp claim, the server cannot invalidate it early without extra infrastructure (e.g., a blacklist or short‑lived access tokens combined with refresh tokens). This makes logout or immediate privilege revocation difficult.

Stale Claims

If a user's role or permissions change, any previously issued JWT continues to grant the old privileges until it expires, potentially exposing privileged operations.

Lack of Confidentiality

The payload is only Base64Url‑encoded, not encrypted. Anyone who intercepts the token can read its contents. If a weak signing algorithm is used (e.g., none or an outdated RSA key), an attacker may also forge or tamper with the token.

Security Best Practices

Use strong, up‑to‑date algorithms (e.g., HS256 with a sufficiently random secret, or RS256 / ES256 with properly managed key pairs).

Keep exp short (minutes to a few hours) and issue refresh tokens for longer sessions.

Transmit tokens only over HTTPS and store them in HttpOnly, Secure cookies when possible to mitigate XSS.

Implement token revocation mechanisms such as a server‑side blacklist, rotating signing keys, or using opaque reference tokens.

Validate all standard claims ( iss, aud, nbf, exp) and reject tokens with unexpected values.

https://jwt.io/

https://research.securitum.com/jwt-json-web-token-security/

https://www.freebuf.com/articles/web/375465.html

Conclusion

JWTs are well‑suited for short‑lived, stateless access tokens that need to be passed between services or APIs. However, they are ill‑adapted for long‑term session storage because of size overhead, revocation difficulty, and the fact that payloads are not encrypted by default. For persistent user sessions, traditional HttpOnly signed cookies or server‑side session stores remain a safer and more efficient choice.