auditing-jwt-verification-trust

name	auditing-jwt-verification-trust
description	Audit code that verifies a JSON Web Token for a signature or claims check that trusts token-supplied parameters, so an attacker can forge a token the server accepts, after the algorithm pinning and the key source are resolved. Covers an algorithm taken from the token header rather than pinned server-side, an RS256-to-HS256 key confusion where a public key is used as an HMAC secret, an accepted none algorithm or a verification call with signature checking off, a kid, jku, or x5u parameter sourcing a key from an untrusted location, audience, issuer, and expiry claims left unchecked, and an HMAC secret that is weak, guessable, or committed. Use when reviewing the verification call and its options in source, not the token-generation entropy the randomness skill owns or the OAuth flow the OIDC skill owns. A token with an attacker-chosen header or bytes is the source, a verification call that gates identity is the sink, and an unpinned algorithm or a token-sourced key is the bug.
license	MIT

Auditing JWT verification trust: when a signed token is verified on the token's own terms

A JSON Web Token is only as trustworthy as the verification code, and the bug is verification that trusts what the token itself supplies: the algorithm from the header, the key from a header-named location. If the server accepts the token's alg, an attacker switches a signature-verified token to an HMAC one signed with the public key, or to none; if it fetches the key from the token's kid, jku, or x5u, the attacker points it at a key they control. You audit it by resolving whether the algorithm is pinned server-side and where the verification key comes from, then checking the claims. This is a source-code audit: the whole value is deciding whether a reported token flaw is actually reachable in this codebase, so the false-positive killers carry the weight. Token-generation entropy belongs to the randomness skill; the OAuth grant dance belongs to the OIDC skill.