add support for supplying multiple public keys, in order to gracefully support certificate rotation #240
Conversation
This file contains 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
… when validating a token signature this facilitates the supporting of certificate rotation, and there being multiple valid keys available during a rotation cycle
|
superseded by PR #241 |
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.
We have a requirement for multiple public key to be valid for a period of time whilst performing a certificate rotation. A rotation across the whole global infrastructure is a non atomic operation that can potentially take some time to roll out. During this time, client requests may be initiated using either the current 'old' key, or a new key that is being rolled out, until such a time as the new key is fully rolled out.
It is therefore desirable for the service receiving the requests to be able to validate signatures generated with either of those keys.
This change exposes via the SigningKeyResolver interface, the ability to supply either a single key (using the existing signatures) or a Collection of keys via the new methods added here. The remainder of the change should be transparent to the application, it is mainly plumbing to get the collection of keys to the various signature validator implementations and having them iterate over a list of possible keys untill one matches.
I appreciate that there would be further work needed to update the test suite, but i wanted to post this PR at this point first to get some feedback on this approach before going any further