JWT authentication looks deceptively simple. You sign a payload, hand it to the client, and every subsequent request carries proof of who the caller is. No session table, no sticky load balancers, no fuss. That simplicity is exactly why so many implementations end up with holes in them. Most failures aren't exotic; they come from a handful of decisions made early and never revisited. Here are the ones worth checking in your own codebase.

Weak Secrets and Leaked Signing Keys

If you sign tokens with HMAC, the secret is the whole security model. Anyone who guesses or obtains it can mint a token for any user, with any role, and your application will accept it without hesitation. Yet secrets still get committed to Git, copied between environments, or chosen by a human who wanted something memorable.

Avoid anything that reads like a password. Generate the secret at random — a 32-byte minimum, ideally 48 or 64 — using your platform's tooling, for example openssl rand -base64 48. Keep it in a secret manager or an environment variable rather than a config file in the repository, and use a different secret per environment so a compromised staging build cannot be turned against production.

If you use asymmetric signing such as RS256 or ES256, the private key deserves the same care, plus a rotation plan. Publish verification keys through a JWKS endpoint with a key ID, keep the old key available for at least as long as the longest token lifetime, then retire it properly.

Tokens That Outlive Their Usefulness

An access token with no expiry, or one measured in months, is a session that can never be reliably closed. If it leaks, you have handed over long-term access, and your only remedy is to rotate the signing key and log everybody out.

The usual fix is two tokens: a short-lived access token — five to fifteen minutes suits most web applications — and a longer refresh token that lives server-side, is rotated on each use, and is revoked on logout or password change. The refresh token is the one you can actually invalidate.

Validate the claims you set, too. Check exp, nbf and iat on every request, and allow only a small clock-skew leeway, a minute or two at most. A generous skew window quietly extends the life of every token you issue. And remember that expiry is enforced by your server, not by whichever client happens to be holding the token.

Algorithm Confusion and the "none" Headache

The token header contains an alg field, and that field is attacker-controlled. Libraries that read it and verify accordingly have produced some of the best-known JWT vulnerabilities: tokens signed with "none", or RS256 tokens re-signed as HS256 using your public key as the HMAC secret.

The fix is straightforward: pin the algorithms your application accepts and pass them explicitly to the verification call, rather than letting the token decide.

• Accept exactly one algorithm family per token type, and reject everything else.
• Never treat a public key as a shared secret.
• Resolve key IDs against a fixed, trusted key set — do not fetch a URL supplied in the kid header.
• Reject unsigned tokens outright; "none" has no place in production.

If several services verify the same tokens, keep library versions current and give each service the same explicit configuration. Consistency matters far more here than cleverness.

Trusting the Payload More Than You Should

A JWT payload is base64url-encoded, not encrypted. Anyone holding the token can read every claim inside it. Do not put email addresses, internal identifiers, permissions you would rather not disclose, or anything else sensitive in there. If you genuinely need confidentiality, use encrypted tokens or, better, keep the data server-side and put only an opaque reference in the token.

Signing proves the token came from you. It says nothing about whether the claims are still true. Check the issuer and audience so a token minted for one service cannot be replayed against another, and confirm that a refresh token cannot be used as an access token. For sensitive operations, re-check permissions against your own data instead of trusting a role claim that may be hours old.

Storing Tokens Where Scripts Can Reach Them

Putting access tokens in localStorage or sessionStorage is convenient and risky. Any cross-site scripting flaw becomes full account takeover, because the token is readable by any script on the page. For browser sessions, an httpOnly, Secure, SameSite cookie is usually the safer home, paired with proper CSRF protection. Keep tokens out of URLs, query strings, referrer headers and log files.

Native and desktop applications should use the platform keychain or keystore rather than a plain file. Everything must travel over HTTPS; a token sent over plain HTTP is a token given away.

No Plan for Logging Out

Stateless tokens do not disappear when a user clicks log out. If that matters — and for anything with real accounts it does — you need a deliberate answer rather than a shrug. The workable options:

• Keep access tokens short and revoke the refresh token on logout.
• Store a token version or a "tokens valid from" timestamp per user, and invalidate it on password change.
• Maintain a denylist of jti values for rare high-risk cases, with entries expiring no later than the tokens themselves.

Choose one, document it, and test it. An unrevocable token is a support ticket waiting to happen.

Before You Ship: A Short Checklist

1. Secrets are random, at least 32 bytes, environment-specific and stored outside the repository.
2. Every token has a short expiry, and exp, nbf, iat, iss and aud are all validated.
3. Algorithms are pinned during verification, and unsigned tokens are rejected.
4. Nothing sensitive sits in the payload, and refresh tokens cannot be used as access tokens.
5. Tokens are stored in httpOnly cookies or platform keystores, never in URLs or logs.
6. Logout, password change and key rotation all have a working path.

None of this is complicated, but all of it needs doing before the first production deploy rather than after the first incident. If your tokens come from an external identity provider, confirm which of these controls it handles for you and which remain yours. That boundary is often less obvious than the documentation suggests.

Photo: Nathan Thomas / Pexels