-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow_nil_kid
option for the JWK KeyFinder
#543
Conversation
Makes sense, gets a little hacky like this when we need to keep backwards compatibility. Would you still be kind to add a changelog entry into the |
I went ahead and added a simple type check on the I think there are few applications which handle the case where Personally, I think that if such people exist, they will also be able to fix their code easily and would be comfortable taking a chance here, but strictly speaking it is a backwards-incompatible change and you may also simplify this with the next major version. Your choice :) |
I think it's great. Just added very small suggestion:) |
Thank you for your contribution. |
Small suggestion: Keep a list somewhere (markdown list in a meta/tracking issue, for example) with stuff you want to update in the next major. In this case, flipping default behavior. |
`allow_nil_kid` option was introduced in jwt#543, but the option name was wrong in README. This change fixes the typo.
`allow_nil_kid` option was introduced in #543, but the option name was wrong in README. This change fixes the typo.
When a JWT does not specify a
kid
explicitly in its header, its key may still have to be fetched from a JWKS.This may happen e.g. when there is only one key in the JWKS and thus there is no need to specify an ID.
This PR adds a decoding option
:allow_nil_kid
, which, when used in conjunction with the:jwks
option, prevents an error from being raised when the JWT does not specify thekid
.In this case, the first key in the provided JWKS is used as the decryption key.
To prevent application jwks-handlers from being overwhelmed by a sudden nil in the options hash, the functionality is disabled by default. (To be fair though, there are no type checks on
kid
and this is all before any verification has happened, so applications should have implemented the necessary checks anyways. So there is an argument that one could just make this the default. :D)