jwtk
add support for supplying multiple public keys, in order to gracefully support certificate rotation
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
Coverage decreased (-2.6%) to 97.419% when pulling c1e9e9e60e7dc8dd17c995e895c7f1e651a9b310 on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.
Coverage decreased (-0.4%) to 99.633% when pulling ef42b0d616af4bc59b5c81e5830413113cb0d0b3 on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.
Isn't this behavior usually achieved using Key IDs? (kid field on the JWT header)
@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
Coverage decreased (-0.3%) to 99.725% when pulling 2191bf8a5a64fa43932da220bc8582dcea4c9eb9 on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.
Coverage decreased (-0.2%) to 99.818% when pulling 25860fb74897022d1061b4efcd2d72c2086f83eb on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.
Coverage decreased (-0.09%) to 99.909% when pulling 3affd83313a2f5080ee1f03625c6401878fbc51e on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.
Coverage remained the same at 100.0% when pulling c1c25bab204c273b259402e505939853a677e4a3 on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.
Coverage remained the same at 100.0% when pulling 1e22d8fa619adcf740bd73d573373cc6f7fc26ac on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.
Coverage remained the same at 100.0% when pulling abde7e0ce0625f09dfaedd919ebe0acaaa5b96dc on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.
Coverage remained the same at 100.0% when pulling aebb76fa719efe3f77777e49bd1f320e6e7b5b5a on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.
Coverage remained the same at 100.0% when pulling 7bb498f82406c01a8b9d2520ed5ebb42983d476c on thepeachbeetle:attempt-1 into 8797f1d04f928ef6db76728f595c74520e8504e9 on jwtk:master.