Signing Keys Management
Learn how SecureAuth allows you to manage your signing keys. Find out what signing keys are and how the management of keys can affect your system security.
Keys Management in a Nutshell
OAuth 2.0/OpenID Connect authentication and authorization relies heavily on issuing access tokens or OpenID Connect ID tokens that are used as a temporary representation of the users' or clients' credentials. Such tokens are signed using cryptographic signing keys. Even though tokens signed using signing keys are a much safer way of providing authentication or authorization than using user credentials, given enough amount of computation power, they can be defeated and unencrypted.
For security reasons, and, more precisely, to protect your data from someone using a compromised token, SecureAuth allows you to manage your signing keys. They can be rotated and revoked manually. You can also set up the automatic key rotation mechanism that rotates keys according to a defined schedule for your authorization workspace.
Security Recommendation
SecureAuth recommends to set up periodical signing key rotation for security reasons.
SecureAuth uses only one JWT signing key at the time, but you can store multiple keys as a part of the JSON Web Key Set (JWKS) that was defined for your application. Rotating a key means that the key you have used so far is no longer used for signing new tokens, but is still used for token validation. You can check your previously used keys as they are stored in SecureAuth. In case of security breach, you can rotate and revoke keys. This gives you a possibility to immediately react to any data being exposed through compromised tokens. It also means that when you revoke a key, it is immediately no longer valid and any attempt to authenticate using a token signed with that key fails. It is also not used for signing tokens any more.
Automatic Rotation Schedule Example
Below, you can find a timeline that illustrates an example of an automatic key rotation schedule. All signing keys are represented by the key ID.
 |
Key Rotation in Depth
In web environment, proper and secure management of cryptographic keys, in this case, signing keys, is crucial for the effective use of cryptography for security.
Cryptoperiods
National Institute of Standards and Technology (NIST) defines cryptoperiods as a timespan during which a specific key is authorized for use by legitimate entities. In other words, cryptoperiod is the length of time a specific key can be used before it becomes invalid and needs to be changed. After the key reaches its cryptoperiod, it should be rotated for security reasons.
NIST recommends that the cryptoperiod for private keys should not be longer than one to three years and it should be revoked after it reaches its cryptoperiod.
For public keys, NIST recommends using a particular public key up to a couple of years. Note, however, that the longer a key is valid, the more it is vulnerable to hostile attacks.
SecureAuth allows to use public signature keys even if the cryptoperiod for the corresponding private signature key has expired. It allows to verify tokens which timestamps are within the cryptoperiod of the private signature key.
To know more about NIST recommendations on cryptoperiod for specific key types, see NIST Recommendation for Key Management, section 5.3.5.
Key Rotation in SecureAuth
You can configure your signing keys in your workspace settings. You can set up the automatic key rotation mechanism there. You can manually rotate key for security purposes. In this case, you can either rotate the key currently in use or rotate and revoke the key.
SecureAuth stores up to 8 rotated keys and up to 16 revoked keys.
SecureAuth supports two types of algorithms to sign tokens: ECDSA and RSA. By default, authorization servers use the ECDSA algorithm to sign tokens except servers of the Workforce type that use the RSA algorithm. You can choose your key type when rotating keys. If you set your key, for example, to be of the RSA type, all next rotated keys are of the type you had chosen.
 |
Warning
When you opt to change key type, it carries implications for client configurations. For example, if you transition from ECDSA to RSA, you will need to make adjustments to the ID Token Signing Algorithm and Authorization Response (JARM) signing algorithm within your client's configuration.