auditing-jwt-verification-and-key-trustlisted

# Auditing JWT verification and key trust: the token names its own signer unless you stop it A JSON Web Token is a signed claim, and its security is entirely in how the verifier checks the signature and the claims. The failures are a small, famous set, and they recur because the token itself carries the parameters an attacker wants to control. The algorithm lives in the token header, so a verifier that trusts it can be steered into algorithm confusion, verifying an RS256 token as HS256 using the public key as the shared secret, or accepting an algorithm of none with no signature at all. The key can be selected from the header too, a key id, a JWKS URL, or an embedded key, so a token can name a signer the attacker controls. A verifier that decodes the token and reads the claims but never actually checks the signature accepts anything. And a verifier that checks the signature but not the expiry, issuer, and audience honors expired or wrong-context tokens. The audit pins the algorithm and key on the server side and confirms the signature and claims are enforced. You audit this by presenting manipulated tokens and confirming each is refused. ## When to use - A service accepts JWTs and verifies them to authenticate or authorize a caller. - The signing algorithm or key may be chosen from token-supplied fields (alg, kid, jku, embedded key). - Claims such as expiry, issuer, and audience may be parsed but not enforced during verification. ## Scope check Test JWT verification only