JWT (JSON Web Token) Security: Correct and Incorrect Use

A JWT (JSON Web Token) is a signed, self-verifying token that carries identity and authorization data. It is very common in APIs and session management. But a JWT’s security depends entirely on being validated correctly; classic mistakes can lead all the way to authentication bypass.

How a JWT works

A JWT has three parts: header, payload, and signature. The header names the signing algorithm, the payload carries claims (who, expiry, permissions), and the signature verifies the token was not altered. The server decides whether to trust the token by validating the signature.

Critical point: a JWT’s payload is signed but not encrypted. Anyone can read its contents (base64); the signature only guarantees it was not changed. So never put secrets inside a JWT.

Classic security mistakes

1. Accepting alg: none: some libraries skip signature validation if the header says “none.” An attacker sends alg: none with an unsigned token to impersonate anyone. The server must decide which algorithm it accepts; it must not trust the algorithm in the token header.
2. Algorithm confusion (RS256 → HS256): if the server expects asymmetric verification (RS256), an attacker can send a symmetric (HS256) token and use the public key as the “secret.” Pin the expected algorithm strictly.
3. Weak signing secret: a predictable/short secret in HS256 lets the signature be cracked. Use a strong, random secret.
4. Expiry and revocation issues: JWTs are usually stateless — valid until they expire. Long-lived tokens are dangerous if stolen. Use short-lived access tokens plus controlled refresh; consider a revocation mechanism for critical cases.
5. Insecure storage: keeping the token in XSS-exposed localStorage turns an XSS into account takeover. Consider safer options like HttpOnly cookies depending on context.

Summary

JWTs are powerful but “all in the validation.” Secure use: let the server pin the accepted algorithm (block alg: none and algorithm confusion), use a strong signing secret, keep expiries short, and never put secrets in the payload (it is not encrypted). Store tokens securely; a JWT does not replace an authorization check.

Sources: RFC 8725 (JWT Best Current Practices), OWASP JWT Cheat Sheet.

Is JWT validation correctly configured in your APIs? CyberTestify’s active verification assesses authenticated API flows.