Assume JWK is valid for signing if "use" is omitted

[Klavionik]

There's an issue #626 about this problem. I ran into it today too.

Currently, when getting signing keys, PyJWKClient assumes that a key is intended for signing, only if its "use" claim is set to "sig". This is not entirely correct, as this claim is optional. If it's omitted, then the key can be used both for signing and encryption.

I guess the correct way to process fetched keys is to check that their "use" claim is either "sig" or missing. In this case, we can safely append it to the list of signing keys.

[dajiaji]

It's a small fix and I think it should be merged.

[yhaojin]

I also ran into this issue today where I was trying to get signing keys from a jwks endpoint without the key "use", and the error PyJWKClientError("The JWKS endpoint did not contain any signing keys") was raised.

Refer to rfc7517 section 4.2:

The "use" (public key use) parameter identifies the intended use of the public key. The "use" parameter is employed to indicate whether a public key is used for encrypting data or verifying the signature on data.
...
The "use" value is a case-sensitive string. Use of the "use" member is OPTIONAL, unless the application requires its presence.

One workaround that I did was to overwrite the get_signing_keys to remove the requirement. I definitely support this PR to be merged.

[jpadilla]

Thanks! I think there might still be some cases we're missing. If you're up to it, it'd be great to compare notes/behavior against https://github.com/panva/jose/blob/main/src/jwks/remote.ts#L100

[Klavionik]

As for the "use" claim, that library has a similar behavior - "check if the claim is present in the object, and only then check that it's set to "sig". Otherwise, just ignore this claim during the check pipeline."

Overall, its behavior and checks are more complex, that's for sure. Though we could implement check for the key_ops array, as it is a bit similar to "use" and specifies uses for the JWK.

[jpadilla]

@Klavionik mind adding a line for this in the CHANGELOG? thanks again

[Klavionik]

@jpadilla I've updated the changelog. Realized I messed up the committer name, had to manipulate the history and force-push the branch. First time contributing and pretty nervous, sorry about that. :)