FHIR Chat · Are servers required to validate the jku header? · bulk data

Stream: bulk data

Topic: Are servers required to validate the jku header?

view this post on Zulip Lee Surprenant (Sep 15 2021 at 16:47):

inferno Auth-18: Token endpoint validates the jku token header claims that servers should reject a JWT if it has a jku that doesn't match the jwks url that the client was registered with.

Keycloak seems to ignore the jku header.
The SMART Backend Services spec does have the following from http://build.fhir.org/ig/HL7/bulk-data/authorization.html#signature-verification

To resolve a key to verify signatures, a FHIR authorization server SHALL follow this algorithm:

If the jku header is present, verify that the jku is whitelisted (i.e., that it matches the JWKS URL value supplied at registration time for the specified client_id).
If the jku header is not whitelisted, the signature verification fails.

So in this case I think the test is accurately testing what is in the specification. What was surprising to me is that this goes beyond standard JWT validation.
What is the rationale for being so stringent on this jku field...is it important for security?

view this post on Zulip Josh Mandel (Sep 15 2021 at 17:53):

The aim is to ensure that a client registers its JWKS URL(s) ahead of time; we already require that registration needs to result in a client having registered a JWKS URL and/or directly registering a JWKS (but that option is less relevant here).

So, if a client has registered JWKS URLs ahead of time, why would it be embedding a different JWKS URL in its access tokens? (I agree with your point Lee that ignoring these should be safe, but the presence of an unexpected JWKS URL in one of these tokens implies that something unexpected is going on... and we'd rather avoid that.)

view this post on Zulip Lee Surprenant (Sep 15 2021 at 18:09):

Yeah, it sound fine to me in principle. Its just that this popular OIDC implementation happens to ignore it and that means it can't pass this test. So it makes me wonder if its better/easier to try loosening the constraint or patching the server impl. I wonder whether other OIDC servers that support JWT do this validation of the jku or not. Any good way to find that answer?

view this post on Zulip Josh Mandel (Sep 15 2021 at 18:23):

I don't know how to find answers, other than asking developers for other OIDC servers.

If we wanted to relax the language it'd be to say something like:

  • Servers MAY use the jku claim as a hint about which keyset to use, after validating that the value is part of a client's pre-registered list of JWKS URLs
  • Servers SHALL NOT dereference the jku if it is not part of a client's pre-registered list of JWKS URLs

^^ ?

view this post on Zulip Lee Surprenant (Sep 15 2021 at 18:39):

yes, exactly

view this post on Zulip Lee Surprenant (Sep 15 2021 at 18:41):

i'm also willing to look into plugging this conformance gap in keycloak...but first wanted to understand how important validation of jku is in practice. I can try it in a couple other OIDC servers that I have access to and it might help shape my opinion...honestly not sure what is best in this case

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -