x5u (X.509 URL) Header Parameter in a JWT

Where jku points at a key set, x5u points at certificates, which brings a trust chain along with it. The resource is PEM encoded, the signing certificate comes first, and each subsequent certificate certifies the one before it. RFC 7515 requires the same protection on the fetch as jku: a protocol with integrity protection, meaning TLS with a validated server certificate.

The forgery route is identical. An attacker publishes a self signed certificate, points x5u at it, and a verifier that downloads and uses the key inside validates the attacker's token perfectly. The presence of a certificate makes this feel more official than an embedded raw key, which is precisely why it slips past review more easily than jwk does.

The request forgery risk is identical too. A URL from an untrusted token becomes an outbound request from a backend host, which is how internal services and cloud metadata endpoints get reached from outside. Neither problem is solved by the certificate: a certificate is only meaningful once its chain has been validated to a trust anchor you configured, and its subject checked against the issuer you expected.

That final check is the one most often skipped. Validating the chain to a public trust anchor proves somebody obtained a certificate, not that this issuer signed your token, so the subject or a pinned thumbprint has to be checked as well. Most deployments do not need any of this: put the key set location in configuration. The decoder does the equivalent, taking the PEM public key from you and never following a URL from a header.