Using JWT correctly: common security mistakes

JWT (JSON Web Token) is a common way to carry identity and authorisation information between APIs. It looks simple: three parts separated by dots. Most mistakes come from that apparent simplicity. The list below gathers the points every team that issues and verifies tokens should review; for detailed recommendations see RFC 8725, which covers JWT security best practices.

1. A JWT is not encrypted

The header and payload of a signed JWT are only base64url-encoded; anyone can read them. Do not put passwords, identity numbers or confidential business data in the payload. If confidentiality is needed, use the encrypted form (JWE), or carry only a reference number in the token and keep the data on the server.

2. Decoding is not verifying

Decoding the payload and reading "user: ayse, role: admin" does not show that the token is genuine. Trust arises only after the signature is verified with the key. Server code that only decodes and trusts the fields lets anyone write their own token.

3. "alg": "none" and algorithm confusion

The alg field in the header comes from the token itself; an attacker can change it. The verifier must take the algorithm to accept from its own configuration, not from the header. "none" must never be accepted, and a token signed with a public key (RS) must not be "verified" with HS by using that same key as a secret.

4. Not checking expiry and audience fields

• If the exp (expiry) field is not checked, the token stays valid forever.
• If iss (issuer) and aud (audience) are not checked, a token issued for another service also passes on your API.
• nbf (not before) and clock skew: a few minutes of tolerance between servers is enough, not hours.

5. A long-lived access token

An access token should be short-lived (minutes), with a separate refresh token to extend the session. A stolen long-lived token can be used with full authority until the theft is noticed.

6. Where it is stored

A token in localStorage in the browser falls into the hands of any script that leaks into the page (XSS). In a cookie with the HttpOnly and Secure flags and a suitable SameSite setting, it cannot be read by scripts; but if you use cookies you must also think about CSRF. No option is sufficient alone.

7. Not being able to revoke

A JWT is a self-contained token; to cancel it before expiry the server needs an extra mechanism (a deny list, a session version, a short lifetime). The token of a user who logs out or loses authorisation stays valid until it expires; accept that in the design or close it.

8. A weak HMAC key

With shared-key algorithms such as HS256, a guessable or short key can be cracked by offline trial. The key should be randomly generated, long enough and stored apart from the code.

How to use the tool

You can open a token in your browser with the JWT decoder to see the header, payload, time fields and weak settings; the token is not sent anywhere. The tool decodes, it does not verify: real verification must be done on your server with the key. To try signature logic there is the webhook HMAC signature verifier, and for keys the password strength and entropy calculator. To review your API security, get in touch.