-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Have a set of keys instead of just one #45
Comments
Why point 3? Why the B cannot be be used after generation? |
Point 3 gives backends ("resource servers") time to fetch this new public key B, so that they are aware that this is a valid key. As it is not used yet to sign JWTs, the window for backends to perform the fetch is exactly that time. Without point 3, LS would be signing JWTs with new key, which backends will not be aware of until they refetch keys. Though backends can do always refetch keys from LS when verification of JWT fails (particularly if key ID This ticket is just a proposal for now, nothing that is decided yet, we'll need to check what the industry standard is. |
#45 a suggestion to add sso to be able to use `aws sso login` to dev-launch LS
* Added Version Stage search to AwsSecretsUtils * Implement keyConfigs to fetch Previous Keys if available * Implement keyConfigs to fetch Previous Keys if available * Implement JWTService * Implement Tests * #45 a suggestion to add sso to be able to use `aws sso login` to dev-launch LS * Use new PublicKeySet * Setup key phase out process * Implement testing for phasing out keys * Implement changes * Simplify AwsSecretsUtils call for create date to one call --------- Co-authored-by: Daniel K <[email protected]>
Background
To allow more UX-friendly keys rotation, having a set of keys for signing JWTs is needed. Once a set of keys is used, the "oldest" one can stop signing keys for time equal to
expiration
of JWT set in config. After that time, it can be replaced with new one.Example (more smooth rotation):
A set of keys is also useful if we for some reason will have to revoke some JWTs, as we would only have to revoke one key from a set, leaving more users unaffected.
Feature
Have a set of keys for signing JWTs, each key having its own unique ID, and add this ID to header of JWT.
The text was updated successfully, but these errors were encountered: