A Token Is Only as Strong as Its Verification
A JWT carries claims protected by a signature. The security depends entirely on verifying that signature correctly. Several well known mistakes let attackers forge tokens.
The Classic Failures
- The none algorithm. Some libraries once accepted a token whose header declared the algorithm as none, treating it as already valid. Always reject none and pin the expected algorithm.
- Algorithm confusion. A token signed with a public key as if it were an HMAC secret can validate if the server blindly trusts the header algorithm. Never let the token choose between asymmetric and symmetric verification.
- Trusting the header. The token header is attacker controlled. Decide the algorithm and key from your server configuration, not from the token.
- Skipping claim checks. A valid signature is not enough. Verify issuer, audience, and expiry so a token for another service or an expired one is rejected.
The safe pattern is to fix the algorithm and key on the server, verify the signature, then validate the claims. Decoding a token without verifying must never grant trust.
Key idea
JWT security rests on verifying the signature with a server chosen algorithm and key, never trusting the token header, and then checking issuer, audience, and expiry, since none algorithm and algorithm confusion bugs let attackers forge tokens.