jku (JWK Set URL) Header Parameter in a JWT

The intended use is a federation where the verifier already knows and trusts a set of issuer hosts, and needs to be pointed at the right key set among several. Even then RFC 7515 requires the fetch to happen over a protocol with integrity protection and server authentication, meaning TLS with a validated certificate, because a key set retrieved over an unauthenticated channel is worth nothing.

Fetching whatever URL the token names hands over the entire trust decision. An attacker signs a token with their own key, publishes the matching public key on a host they control, points jku at it, and the verifier obligingly downloads the key that makes the forgery valid. Every claim in the token, including who the subject is, is then whatever the attacker wrote.

The second problem is server side request forgery. The verifier is often a backend service with network access nobody outside is meant to have, and jku makes it issue a request to a URL an outsider chose. Cloud metadata endpoints, internal admin interfaces and anything else reachable from that host become targets, and the response may even come back in an error message.

The safe handling is an allowlist of exact URLs, or of exact hosts with a fixed path, decided in configuration, plus a strict scheme check, no redirect following, a timeout and a cache. In most deployments the honest answer is simpler: ignore jku entirely and configure the key set location yourself. The decoder takes that position by never dereferencing anything from a header, and asking you to paste the PEM public key instead.