auditing-jwt-verification-trustlisted

# 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. ## When to use - You are reviewing the code path that verifies a signed token and uses its claims for an identity decision. - You see a decode-or-verify call, an algorithms option, a key lookup by header parameter, or a claims read. - You want to know whether an attacker can forge a token this verification call accepts. ## Scope check Audit only systems you own or are authorized to assess, and present a crafted token only against an endpoint in scope, a forged token that verifies grants real access. Adjudicate on t