Selecting a key in a JWKS given a JWT header

1
votes

Is there a standard way of selecting a signature verification key in a JWKS key store given a JWS (JWT) header?

My goal is to implement OpenID Connect ID Token validation library and I'm trying to be flexible and anticipate different configurations but I'm not sure if there is a point doing that if key selection is specific to IdP anyway.

My current algorithm walks the JWKS and filters out:

  1. If JWK has "use" field reject if "use" does not equal "sig"
  2. If JWK has "key_ops" field reject if "key_ops" does not contain "verify"
  3. If JWK has "alg" field reject if it is different from JWS header value
  4. If JWS header has "kid" field reject if JWK does not or has different value (note the reversed logic)
  5. If at this stage there is exactly one JWK left I use that one. Otherwise it's a failure.

Is this approach "standard enough"?

=== EDIT ===

I found that there is Section 10.1 of OpenID Connect core spec saying:

When using RSA or ECDSA Signatures, the alg Header Parameter value of the JOSE Header MUST be set to an appropriate algorithm as defined in JSON Web Algorithms [JWA]. The private key used to sign the content MUST be associated with a public key used for signature verification published by the sender in its JWK Set document. If there are multiple keys in the referenced JWK Set document, a kid value MUST be provided in the JOSE Header. The key usage of the respective keys MUST support signing.

JWK "use" is mandatory so I can safely require it to be "sig".

JWT "kid" is mandatory if there's more than one key in JWKS. That suggest (although indirectly) that in this case JWT "kid" and "JWK" kid should match. "kid" is not required to be unique though so you still need additional rules.

2
securityjwtopenid-connectjwk
4. is probably: "If JWS header has "kid" field reject if JWK does not or has different value (note the reversed logic)" i.e. JWS->JWK - Hans Z.
Good spot, cheers! - maciekszajna

2 Answers

0
votes

That is a viable approach. I would argue that at stage 5. you may have ended up with multiple valid keys of the same type if no kid was transferred in the JWS (step 4). You'd loop over those keys and pass them to the verification function one-at-a-time to find out if there's one that succeeds and thus was used to sign the message.

0
votes

I use a similar approach on my project. Look at the method selectKey of the file https://github.com/Spomky-Labs/jose/blob/master/src/Object/BaseJWKSet.php#L169

In a nutshell, the method sort she keys depending in the arguments and returns first one.