Why Many Experts Advise Against Using JWT for Authentication

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.signature. The header typically declares the signing algorithm (e.g., HS256 or RS256), the payload carries the claims (such as sub, exp, role), and the signature is computed over the header and payload using the declared algorithm and a secret key or private key.

How JWT works

When a user authenticates (e.g., logs in), the authentication server creates a JWT containing the user’s identity and any required authorization data.

The server signs the token with a secret (HMAC) or a private key (RSA/ECDSA) and returns the token to the client.

The client stores the token (commonly in memory, local storage, or a cookie) and includes it on each subsequent request, usually in the Authorization: Bearer <token> header.

Upon receiving a request, the resource server verifies the signature using the shared secret or the public key, checks standard claims such as exp (expiration) and nbf (not‑before), and extracts the payload.

If verification succeeds, the server uses the claims (e.g., user ID, roles) to enforce access control for the protected resource.

Why JWT can be problematic

Size overhead

A JWT carries the same logical information as a simple session identifier but its serialized form is larger because it includes the header, payload, and signature. For example, a plain cookie containing a numeric user ID may be ~5 bytes, whereas the equivalent JWT can be 200‑300 bytes, increasing bandwidth and storage requirements.

Redundant signature

Modern web frameworks already provide signed (and often encrypted) session cookies. Adding a JWT on top of such a cookie introduces a second signature without clear benefit, because the same integrity guarantees can be achieved with the framework’s native session handling.

Token revocation

JWTs are self‑contained and remain valid until their exp claim expires. Servers cannot invalidate a token early without additional infrastructure (e.g., a token blacklist). This leads to practical issues:

Logout does not immediately terminate the session; the token can still be used until it expires.

Changes to user privileges (e.g., demotion from admin) are not reflected until the token’s expiration, leaving a window of stale permissions.

Lack of confidentiality

JWTs are only Base64URL‑encoded, not encrypted. An attacker who can intercept the token (e.g., via a man‑in‑the‑middle attack on an insecure channel) can read the claims and replay the token. To protect confidentiality, developers must use TLS and, if needed, encrypt the payload (e.g., JWE).

General security considerations

Research papers and security analyses have identified additional attack vectors, such as algorithm‑confusion attacks, weak signing keys, and token leakage. Relevant references:

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

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

Practical guidance

JWTs are well‑suited for short‑lived, single‑use authorization tokens (e.g., API calls between microservices) where the overhead of a stateful session store is undesirable. For long‑lived user sessions, traditional signed session cookies or server‑side session stores are generally safer because they allow immediate revocation and avoid the size and confidentiality drawbacks of JWTs.