Recommended way to rotate keys

[ndench]

Thanks for the great library!

Just looking for someone to point me in the right direction here. In version 4.2.0 a minor BC break was released if you're using a key length of less than 256 bits. This alerted me that I'm actually using key lengths of 248 bits in production. I currently use this library to generate magic login tokens for my users.

If I just start using a new key, all the existing login links will be invalidated. Which is not something I want to do (since these particular users cannot generate themselves another link, they receive (relatively) short lived login links from other users).

Do you have a recommended way to rotate keys such that old login links still work correctly (at least for a short period of time)?

[Ocramius]

What you could do (pre-4.2.0) is:

1. have an instance of this library with the old key
2. have an instance with the new key
3. When someone interacts with an old key, issue a new token with the new key

[lcobucci]

I think that using custom constraint to validate the signature might be an option.

Imagine something like this:

new VerifySignatureWithFallbackKey(
    new SignedWith(new Hmac\Sha256(), 'new key'), 
    new SignedWith(new Hmac\UnsafeSha256(), 'old key'),
);

Having that new constraint implementing the SignedWith interface would also guarantee compatibility with the new high-level API.

Having key sets and the key id on the token would be amazing, that would also require custom implementation on your end, though.

[SvenRtbg]

I'm pretty sure key ids on the old tokens will not happen in this situation, but to illustrate that more: OpenID Connect has a list of possible keys in JWK format, and each key has a key id (random long string), and that key id is also included in the token as a "kid" claim. So each token knows which key was used to sign it, and a validator can then use exactly that key, fetching it from the list, instead of trying the most recent first, and on failure try another key, and possibly all previously used keys.

In this particular situation, you'd only have to deal with two keys, so the check basically is: Check the new one first. If unsuccessful, check the old key, and issue a new token signed with the new key on success. Remove that old key checks after you are sure all old keys are expired. You can still use 4.2.x when using that UnsafeSha256 for the old key verification.

[kynx]

OT, but see #32 (comment) for some discussion about JWK. I started to have a go at implementing it, but summer life got in the way. Now we're in Sept I'll try and get some example code together.