You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently keep the issuer private key around for the lifetime of the process. If the key is changed then it should be reloaded and propagated throughout the internal structures.
Instead of having a time-based cache for this, I think it'd be better to have a maintenance goroutine that periodically checks/reloads/updates the internal data structures.
In scope for this issue:
Rotating out private key from internal memory structures if the admin provides a new one.
Registering new key with the registry.
Not in scope for this issue:
Generating a new public JWKS file with both old and new keys. It's up to the admin to get the public key set correct.
In the future, we should track when the last known token for a given key expires and automatically merge in prior public keys used by the origin.
Delaying signing tokens with the new key until a public key propagation time period has passed.
Actually generating the new private key itself.
That is, we should assume the origin administrator knows what they're doing when rotating keys. A follow-up ticket can automate the key rotation process.
The text was updated successfully, but these errors were encountered:
We currently keep the issuer private key around for the lifetime of the process. If the key is changed then it should be reloaded and propagated throughout the internal structures.
Instead of having a time-based cache for this, I think it'd be better to have a maintenance goroutine that periodically checks/reloads/updates the internal data structures.
In scope for this issue:
Not in scope for this issue:
That is, we should assume the origin administrator knows what they're doing when rotating keys. A follow-up ticket can automate the key rotation process.
The text was updated successfully, but these errors were encountered: