JWTs: structure, verification, and the mistakes that cause breaches

问题

What the three segments contain, what signature verification actually proves, and the recurring failure modes — alg confusion, none, missing expiry checks, and unsafe storage.

Pasos

1. 1. Anatomy of the three segments

   A JWT is header.payload.signature, each segment Base64URL-encoded. The header names the algorithm (alg) and token type (typ). The payload carries claims: registered ones (iss issuer, sub subject, aud audience, exp expiry in Unix seconds, iat issued-at, nbf not-before) plus whatever your application adds. The signature is computed over the first two segments with the key. All three parts are readable by anyone who holds the token — decoding is not a security event, which is why offline decoders are safe to exist.

2. 2. What verification proves — and what it does not

   Verification recomputes the signature with the key and compares. It proves the token was issued by whoever holds the key and that header+payload were not modified. It does not prove anything inside the payload is true for your context: a valid token for audience A is not valid for audience B, an unexpired token from a revoked session is still cryptographically valid, and claims like role or scope are only as trustworthy as the issuer that wrote them. Verify alg, audience, issuer, and expiry every time — in that order — before reading any claim for authorization decisions.

3. 3. The alg confusion and 'none' attacks

   The alg header is attacker-controlled input. Two historical vulnerabilities remain worth understanding: the 'none' algorithm (a header claiming no signature at all — a verifier that trusts the header accepts forgeries) and algorithm confusion (a token signed with a public RSA key being replayed as HS256, where the public key itself becomes the HMAC secret). The defense is the same in both cases: the verifier pins the expected algorithm and rejects everything else, regardless of what the header claims.

4. 4. HS256 vs RS256 in practice

   HS256 is a symmetric HMAC: the same secret signs and verifies, so every service that can verify tokens can also forge them — acceptable for a single service, risky once tokens are shared across a fleet. RS256 (and ES256) are asymmetric: the issuer keeps the private key, verifiers hold only the public key, so a compromised verifier cannot mint tokens. Asymmetric algorithms also enable JWKS-based key rotation, which is why hosted identity providers default to them.

5. 5. Storage, lifetime, and the practical checklist

   Where a token lives determines its exposure: localStorage is readable by any injected script (XSS turns into session theft), while httpOnly cookies are unreadable to scripts but bring CSRF considerations. Keep access-token lifetimes short (minutes), pair with refresh-token rotation, and include jti plus a server-side denylist when instant revocation matters. The practical checklist: verify signature and pinned algorithm; check exp with clock-skew tolerance; check iss and aud; check nbf if present; and treat every claim as data from the issuer — never as proof by itself.

Resultado esperado

You can decode and inspect all three JWT segments, verify the signature with a pinned algorithm plus exp/iss/aud checks, and recognize the classic failure modes — alg confusion, the none algorithm, missing expiry checks, and unsafe storage.