Refactor KeyProvider to receive the "Key Id"#167
Merged
Conversation
hzalaz
suggested changes
May 3, 2017
README.md
Outdated
|
|
||
| #### Using a KeyProvider: | ||
|
|
||
| By using a `KeyProvider` the library delegates the decision of which key to use in each case to the user. For the verification process, this means that the provider will be asked for a `PublicKey` with a given **Key Id** value. Your provider implementation should have the logic to fetch the right key, for example by parsing a JWKS file from a public domain like [auth0/jwks-rsa-java](https://github.com/auth0/jwks-rsa-java) does. For the signing process, this means that the provider will be asked for a `PrivateKey` and it's associated **Key Id**, so it can set it in the Token's header for future verification in the same way. Check the [IETF draft](https://tools.ietf.org/html/rfc7517) for more information on how to implement this. |
Contributor
There was a problem hiding this comment.
By using a KeyProvider you can in runtime change either the key used to verify the token signature or to sign a new token for RSA or ECDSA algorithms. This is achieved by implementing either RSAKeyProvider or ECDSAKeyProvider methods:
- getPublicKeyById(String kid): Its called during token signature verification and it should return the key used to verify the token. If key rotation is being used, e.g. JWK it can fetch the correct rotation key using the id. (Or just return the same key all the time).
- getPrivateKey(): Its called during token signing and the key will be used to sign the JWT.
- getPrivateKeyId(): Its called during token signing and it should return the id of the key that identifies the one returned by
getPrivateKey()
| }; | ||
| Algorithm algorithm = Algorithm.RSA256(keyProvider); | ||
| //Use the Algorithm to create and verify JWTs. | ||
| ``` |
Contributor
There was a problem hiding this comment.
Below this we can add a note saying that they could use jwks-rsa-java to perform the jwk handling
hzalaz
approved these changes
May 3, 2017
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces changes to better support Key Rotation.
Super classes
JWTno longer implementsDecodedJWT. Users who find this breaking need to update the return type ofJWT.decode()andJWT.require() ... verify()toDecodedJWTinstead ofJWT.JWT parts
Before this PR the
DecodedJWTinstance just allowed to obtain the original version of the token and the signature (third part). Now 2 more methods were added:getHeader()andgetPayload()which return the first and second part of the header as it is, with a Base64 encoding.KeyProvider refactor
Now receives a "Key Id" when asked for the
PublicKey, and also asks for a "Signing Key Id" that will be set in the header of the token in the signing process. If the "Key Id" is being set by the user using thewithKeyId()in theJWTCreatorclass, the library won't overwrite it with the one defined in theKeyProviderimplementation.Users who doesn't use
KeyProvider(i.e. instantiate the algorithm by passing just the keys) or returnnullin thegetSigningKeyId()call will not be affected by this and thekidclaim won't be automatically set.Example usage:
Algorithms
The
Algorithm#verifymethod changed it's signature: Now it will verify a givenDecodedJWTinstance instead of thebyte[]of signature and contents. This was needed to get the "Key Id" claim and request it's associatedPublicKeyto theKeyProvider. Although this is a breaking change, users shouldn't be using the Algorithm class directly as it's purpose is to be called internally by the library.