There is currently no cache control on the JWKS endpoint (/oidc/certs). This creates two problems:
1) You need to refresh the keyset on every login which creates an unnecessary extra call on every login
2) If you do some caching of your own you might miss the new keys after rotation.
My proposal is this
When the key is rolled over - publish the key in the jwks endpoint
wait 7200 seconds and start signing with the keys
add 3600 second cache header for /oidc/jwks
Key rollover can only happen > once every 24 hours (if too difficult, we can also just add a comment in the config file)
This would be more than the spec dictates: In the rollover scenario in the spec it says that when a client finds a kid it does not now, it should reretrieve the keyset. However, the method described above should be more robust against client implementations that just blindly cache the jwks keys for the duration set in the cache headers.
Here is the text from the spec:
Rotation of signing keys can be accomplished with the following approach. The signer publishes its keys in a JWK Set at its jwks_uri location and includes the kid of the signing key in the JOSE Header of each message to indicate to the verifier which key is to be used to validate the signature. Keys can be rolled over by periodically adding new keys to the JWK Set at the jwks_uri location. The signer can begin using a new key at its discretion and signals the change to the verifier using the kid value. The verifier knows to go back to the jwks_uri location to re-retrieve the keys when it sees an unfamiliar kid value. The JWK Set document at the jwks_uri SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a smooth transition.
This issue is imported from pivotal - Originaly created at Jul 9, 2020 by Bart Geesink
1) You need to refresh the keyset on every login which creates an unnecessary extra call on every login 2) If you do some caching of your own you might miss the new keys after rotation.
My proposal is this
This would be more than the spec dictates: In the rollover scenario in the spec it says that when a client finds a kid it does not now, it should reretrieve the keyset. However, the method described above should be more robust against client implementations that just blindly cache the jwks keys for the duration set in the cache headers.
Here is the text from the spec:
Rotation of signing keys can be accomplished with the following approach. The signer publishes its keys in a JWK Set at its jwks_uri location and includes the kid of the signing key in the JOSE Header of each message to indicate to the verifier which key is to be used to validate the signature. Keys can be rolled over by periodically adding new keys to the JWK Set at the jwks_uri location. The signer can begin using a new key at its discretion and signals the change to the verifier using the kid value. The verifier knows to go back to the jwks_uri location to re-retrieve the keys when it sees an unfamiliar kid value. The JWK Set document at the jwks_uri SHOULD retain recently decommissioned signing keys for a reasonable period of time to facilitate a smooth transition.