Who Signs Your Token: Reading jku, kid, iss and aud Correctly

Verifying a signature is two questions, not one. Is the signature mathematically valid, and is it valid under a key you actually trust? Most JWT bugs live in the second question, and this one lives there entirely.

The token names three hosts. iss is https://auth.brightway.example, an identity claim in the payload. aud is https://api.caldera.example, the intended recipient. Neither is a key source, and iss in particular cannot be one: it sits inside the body whose signature you have not checked yet, so using it to choose the key would be circular.

The third is in the header. jku stands for JWK Set URL and it is defined in RFC 7515. It means: the keys that verify this token are published here. A library that honours jku will make that request before it validates anything, which puts jwks.brightway-cdn.example in charge of whether the signature is trusted.

Nothing protects the header. The sender writes it. So an attacker generates a key pair, signs a token carrying any claims they want, publishes the matching public key as a JWK Set on a host they control, sets jku to it, and the verifier downloads that key and confirms the signature. The mathematics is correct throughout. The key was the attacker's.

kid is the field people expect this bug in, and it is not the bug here: prod-2026-08 identifies a key without saying where it lives. The lookalike hostname is the finishing touch. Next to auth.brightway.example, a host called brightway-cdn.example reads like the same company's CDN, and it is a completely separate registration.

• Answering auth.brightway.example. iss says who claims to have issued the token, and it is inside the part you have not verified.
• Answering api.caldera.example. aud is the recipient, checked after verification, never a key source.
• Answering prod-2026-08. kid names a key; it is not a host and not a URL.
• Assuming the header is protected because the token is signed. The signature is only meaningful once you have a trusted key, and the header is what chooses it.
• Reading brightway-cdn.example as brightway.example. They are different registrations, which is the entire point of the name.

Never let a token tell you which key verifies it.

• Disable jku and x5u in the verifier. Most libraries have a flag or an allowlist of header parameters; if yours resolves them by default, that is the setting to change today.
• Pin key discovery to configuration. Map each issuer to a JWKS URL you control, and fetch only from that map.
• Use kid only to select among keys you already hold, never to fetch a new one, and fail closed on an unknown kid.
• Pin the expected algorithm per issuer and reject anything else, so a token cannot switch you to none or to HMAC with a public key as the secret.
• Validate iss and aud after the signature, not before, and alert on any token whose header carries a URL parameter at all. In a healthy deployment that number is zero.