Hiro Tanabe

I take one token and walk through it in order, because the failure modes only separate once all three parts sit next to each other. A JWT is three base64url segments: a header, a payload and a signature. The signature covers the first two, joined by a dot. That structure explains almost every attack, because it means a reader must decide whether to trust the header's contents before it can check anything. That decision is the alg field, and the serious problems live there. A token declaring alg none carries no signature to verify. Worse, a server accepting whatever algorithm the header names can be handed a token where alg says HMAC and the public RSA key is used as the shared secret, producing a signature the attacker can produce themselves. The defence is to ignore the header and configure the expected algorithm, which is what RFC 8725 asks for and what a surprising number of libraries do not do by default. Claims need the same scrutiny. exp and nbf are checked against the clock on the verifying side, so a few minutes of drift is normal and a lot of it is a bug. iss and aud decide which system a token was meant for, and a token skipping either check can be replayed against the wrong service. jti exists for revocation and does nothing unless somebody keeps a list. I cover where the token lives too. localStorage survives a reload and is readable by any script that runs, which turns one injection bug into session theft. Cookies with HttpOnly and the right SameSite setting narrow that, and the trade-off deserves stating plainly.