JWT: How It Works and the Mistakes That Break Authentication

A JSON Web Token (JWT) is a compact, self-describing credential: three Base64URL-encoded parts joined by dots — header, payload and signature. The header names the algorithm, the payload carries the claims, and the signature lets the server trust both without storing session state. A decoded token looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   → {"alg":"HS256","typ":"JWT"}
eyJzdWIiOiIxMDQiLCJyb2xlIjoiYWRtaW4ifQ → {"sub":"104","role":"admin"}
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJVadQss

The classic attacks

• The alg:none attack: the JOSE standard allows an algorithm called none — an unsigned token. Some libraries happily accept it if the application does not pin the expected algorithm. An attacker strips the signature, sets alg to none, edits the payload to role: admin, and walks in. Always whitelist the exact algorithm server-side.
• HS256 vs RS256 confusion (algorithm confusion): HS256 signs with a shared secret; RS256 signs with a private key and verifies with a public one. If a server written for RS256 accepts a token claiming HS256, an attacker can sign forged tokens using your public key as the HMAC secret. Reject any algorithm you did not configure, and prefer RS256 or EdDSA when multiple services must verify tokens.
• Unvalidated claims: expired tokens (exp), wrong issuers (iss) and wrong audiences (aud) must all be checked. A token that never expires is a permanent key.
• Sensitive data in the payload: the payload is plain Base64, readable by anyone who sees the token — the browser, proxies, log files. Never put passwords, card data or secrets there; JWT is signed, not encrypted.
• No revocation story: stateless is convenient until a token leaks. Keep a short lifetime (minutes for access tokens) and a small server-side denylist of stolen token identifiers until they expire.

Where tokens live on the client

• localStorage is readable by any script on the page. Combined with one XSS hole, it hands the attacker a working token. It is convenient, not safe.
• httpOnly cookies cannot be read by JavaScript, which blunts XSS, but they need SameSite and CSRF protection because the browser attaches them automatically.
• Keep lifetimes short. A refresh-token pattern — short-lived access token, longer-lived refresh token with rotation and reuse detection — limits the blast radius of any single leak.

Where JWTs fit

JWTs shine for service-to-service APIs and single sign-on, where a central issuer signs once and many verifiers check. For a simple session inside one application, a plain server-side session cookie is often the simpler and safer choice — no token to leak, no crypto to get wrong.

To inspect a token, paste it into the WhoDNS JWT decoder. It shows the decoded header and payload instantly and runs locally, so untrusted tokens never leave your machine — ideal for checking what claims an API actually issues, how long its tokens live, and whether that alg header is something you should worry about.

🔗 Related tool: Decode and inspect any JWT