Hasura fails to load standards compliant JWKS with unrecognized “use” values.

[JesperWe]

Version Information

Server Version: 2.48.1

Environment

OSS

What is the current behaviour?

When starting up and loading a JWKS specified by the HASURA_GRAPHQL_JWT_SECRET jwk_url Hasura will fail to initialise with the error message

Error parsing JWK from url: https://… 

...if the returned JWKS has keys[].use value not equal to sig or enc.

While those two values are named in the RFC Section 4.2, it also says:



Other values MAY be used.

However Hasura does not accept a JWKS with a key whose use value is not equal to sig or enc.

What is the expected behaviour?

Unrecognized values should simply be ignored.

How to reproduce the issue?

Point the HASURA_GRAPHQL_JWT_SECRET jwks_url to a JWKS with keys[].use values containing for example "saml_ca" (Typically used fot an IdP with SAML support)

Keywords

auth jwks

[seanparkross]

Hi @JesperWe I have passed on to the team. In the meantime can you supply a secret-redacted JWT from the server for us to have a look at?

[JesperWe]

Sure. Here is an example. Just pointing out that it is the JWKS we are talking about, not the JWT.

{
  "keys": [
    {
      "use": "sig",
      "kty": "RSA",
      "kid": "321693135832881917",
      "alg": "RS256",
      "n": "...",
      "e": "AQAB"
    },
    {
      "use": "sig",
      "kty": "RSA",
      "kid": "321728951783267069",
      "alg": "RS256",
      "n": "...",
      "e": "AQAB"
    },
    {
      "use": "sig",
      "kty": "RSA",
      "kid": "321766531002276605",
      "alg": "RS256",
      "n": "...",
      "e": "AQAB"
    },
    {
      "use": "sig",
      "kty": "RSA",
      "kid": "321802769537178365",
      "alg": "RS256",
      "n": "4...",
      "e": "AQAB"
    },
    {
      "use": "saml_ca",
      "kty": "RSA",
      "kid": "321336129393530431",
      "n": "...",
      "e": "AQAB"
    },
    {
      "use": "saml_response_sig",
      "kty": "RSA",
      "kid": "321336135382996543",
      "n": "...",
      "e": "AQAB"
    },
    {
      "use": "sig",
      "kty": "RSA",
      "kid": "321838209426266877",
      "alg": "RS256",
      "n": "...",
      "e": "AQAB"
    }
  ]
}

[seanparkross]

Hi @JesperWe
In waiting for the engine team to find some time, this is what chatGPT o3 has flagged with the validity of the JWKS response:

Mostly ✔️—but two details break strict RFC 7517 compliance

What is valid

Item	Spec requirement (RFC 7517 / RFC 7518)	Your JWKS
Top-level object has a single keys member containing an array	✅	✅
Each RSA JWK contains required parameters kty, n, e	✅	All seven keys have them (ellipsis assumes real Base64URL)
Optional parameters (kid, alg, use) are allowed	✅	Present and plausible
kid values are unique within the set	✅	All IDs differ

What needs attention

Issue	Why it matters	How to fix
use values "saml_ca" and "saml_response_sig" are not registered	use is restricted to the IANA “JSON Web Key Use” registry (currently only "sig" and "enc"). Unknown values can cause some libraries to reject the JWK.	• Replace them with "sig"/"enc" or • Omit use entirely and identify the key by kid, or • Keep the custom data but move it to a different, non-standard field name (e.g. "saml_use":"ca").
One key is missing the optional alg (the two SAML-related keys also omit it)	Legal—alg is optional—but declares nothing about the intended JWT/SAML algorithm. Some validators prefer it present for certainty.	Add "alg":"RS256" (or whatever you actually sign with).

(Minor: the placeholder "n": "..."/"4..." obviously must be a real Base64URL-encoded modulus.)

Bottom line

• If the JWKS is parsed by a tolerant library, it will work—the unknown use values are simply ignored.

• For spec-strict or security-hardened libraries, those two keys will be flagged as invalid and may cause the entire set (or just those entries) to be rejected.

So: change or drop the non-standard use values and you have a fully standards-compliant JWKS.

[JesperWe]

That is just plain wrong. Check the specs: https://www.rfc-editor.org/rfc/rfc7517.html#section-4.2

"Other values MAY be used"

So a file using other values is still strictly according to the spec.

[jberryman]

What is the expected behaviour?
Unrecognized values should simply be ignored.

To be clear do you mean skip over any JWKs in the keys array that we can't parse? If so that seems doable, we would probably need to issue a warning in that case.

Or are you trying to use those keys in hasura?

[JesperWe]

No, not expecting to use those keys in Hasura. Hasura only needs keys to verify publicly signed JWTs.

But I am expecting Hasura to peacefully (as in not throwing errors) coexist with other tools in a larger system where the Identity Provider offers multiple auth types and thus keys used for in this case SAML.