add support for supplying multiple public keys, in order to gracefully support certificate rotation #241
Conversation
… when validating a token signature this facilitates the supporting of certificate rotation, and there being multiple valid keys available during a rotation cycle
This reverts commit f1e1eec.
…ttempted when validating a token signature" This reverts commit ba3ae16.
This reverts commit e8ba619.
…ach private key will be attempted in turn
…gning key resolver this allows existing subclasses of the SigningKeyResolverAdaptor to work un-modified with these changes the new methods are only necessary to override if you wish to take advantage of the ability to supply a collection of keys
|
Isn't this behavior usually achieved using Key IDs? ( |
|
@jcarvalho Yes, whilst you could certainly do that, it is not often possible or practical to enforce upon the client that they specify the correct key id matching the key that they are using to sign. This adds a lot of complexty on both the client side and server side to manage an associated of keys to id's and potential for things to go wrong and be hard to diagnose. The intent of this PR is to take away any of that complexity from a client, to simply give them a new key and say 'start using this as soon as possible, old key is valid until such a time', as long as the service validating the tokens is able to find all the currently valid public keys through its SigningKeyResover, then everything becomes simple and transparent |
…erated by the SigningKeyResolverAdaptor
…tion_Success test to address intermittent test failure
merge with master
merge upstream
Merge pull request #2 from thepeachbeetle/master
merge with upstream
This is a simplified patch and supersedes the previously submitted PR (#240)
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