JWKS Spoofing via Open Redirect: Chaining Trust
Allowlisting a JWKS host is supposed to end the jku debate. Then someone leaves an open redirect on that same host. The JWT library checks that jku starts with https://trusted.example/, follows redirects, and happily parses keys from your server.
That chain is JWKS spoofing. The open redirect is the foot in the door; forged tokens are the impact.
Build it in order
First, find whether the API honors jku, x5u, or a discovery document URL. Many modern libraries disable this. Some enterprise adapters still enable it for multi-tenant OIDC.
Second, map redirectors on the allowlisted origin: /login?next=, language switchers, marketing link wrappers, SAML ACS helpers, or OAuth redirect_uri that bounce through the IdP domain. You need a 302 whose Location you influence to https://attacker.example/jwks.json.
Third, host a JWKS with a keypair you control. Craft a JWT with jku set to the redirect URL on the trusted host, sign with your private key, and present it to the API.
If validation follows redirects and trusts the final body, the API accepts sub values you mint. Stop there for the proof—impersonate an account you own, or a test user the program provided. Do not roam production identities.
Subtle failure modes
Some clients validate the redirect target against the allowlist on every hop; those break the chain. Others only check the initial URL. Document which behavior you observed.
Path-restricted allowlists such as https://trusted.example/oauth2/v1/keys can still fall if the redirect endpoint sits under that path prefix or if path normalization collapses /oauth2/v1/keys/..%2f..%2fredirect.
Caching matters. A poisoned JWKS response cached by the library or an intermediate proxy can outlive your test. Use a unique kid and clean up.
Redirectors that only allow relative paths still help if you can bounce to a path that itself 302s externally—open redirect chains of two hops are annoying to explain and very real. Capture each Location header. Triage should not have to guess the hop count.
How to describe severity
Lead with account impersonation capability, not the redirect alone. Programs may have marked the redirect as low until you attach token forgery. Give them the full chain: allowlist check → redirect hop → attacker JWKS → accepted forged JWT → authenticated request as victim test user.
Fix on both sides: do not follow redirects when fetching JWKS; pin exact JWKS URLs; disable jku from untrusted tokens; eliminate open redirects on identity hosts. Either break alone may be enough; both is the durable answer.
If you only control the redirect and cannot get the JWT library to honor jku, file the redirect on its own merits and note the JWKS risk as residual. Stretching an incomplete chain into "auth bypass" is how solid research gets a polite N/A.
Serve your JWKS with the exact content type and shape the library expects—keys array, correct kty, matching kid in the header. A forged token rejected for JSON shape looks like a failed exploit when the trust chain actually worked. Keep a known-good JWKS fixture ready before you start flipping redirect parameters.