JWT jku Header
The jku header parameter points to a URL hosting a JWK Set that may contain keys for verifying the token signature. In theory it lets issuers publish keys dynamically per token. In practice, blindly fetching jku from an untrusted token enables attackers to host malicious JWKS documents and forge signatures that a naive verifier accepts as valid. Secure deployments ignore untrusted jku values and configure a known JWKS URI out-of-band through issuer metadata. If you must support jku, allowlist exact HTTPS hosts, enforce modern TLS, cache keys carefully, and still match kid to an expected key entry. Prefer static JWKS configuration for first-party APIs and internal microservices wherever possible.
Why It Matters
Remote key discovery without allowlists turns your verifier into an open client toward attacker-controlled cryptographic material. Many JOSE incidents stem from trusting header-supplied URLs. Keep key distribution under your operational control via configured jwks-uri values, monitoring, and rotation playbooks — not attacker-influenced jku headers on inbound bearer tokens. Wire verifiers to a configured issuer JWKS URL, log rejected remote-key attempts, and fail closed when unexpected jku values appear. Treat any production dependency on client-supplied key URLs as a security exception requiring written approval and host allowlists.
Related Terms
Related Comparisons
Related Tools
Related Articles
Frequently Asked Questions
Should my API honor jku from clients?
No for typical first-party APIs. Configure a trusted JWKS URL yourself, ignore inbound jku, and alert if clients send unexpected remote-key hints that look like probing.
How is jku different from jwks-uri?
jku is a per-token header hint. jwks-uri usually refers to issuer metadata you configure as the source of truth for public keys.
Can jku be used safely at all?
Only with strict host allowlists, HTTPS, caching, and pinning policies — and even then most first-party APIs still prefer a configured JWKS URI and ignore inbound jku entirely.