Signing Keys

When you select our recommended signing algorithm (RS256), Auth0 uses public-key cryptography to establish trust with your applications. In more general terms, we use a signing key that consists of a public and private key pair.

Signing keys are used to sign ID tokens, access tokens, SAML assertions, and WS-Fed assertions sent to your application or API. The signing key is a JSON web key (JWK) that contains a well-known public key used to validate the signature of a signed JSON web token (JWT). A JSON web key set (JWKS) is a set of keys containing the public keys used to verify any JWT issued by the authorization server and signed using the RS256 signing algorithm. The service may only use one JWK for validating web tokens, however, the JWKS may contain multiple keys if the service rotated signing certificates.

How it works

When a user signs in to your application, we create a token that contains information about the user and sign the token using its private key before we send it back to your application. Auth0 secures the private key, which is unique per tenant.

To verify that the token is valid and originated from Auth0, your application validates the token’s signature using the public key. We provide other application security key management capabilities through both our Dashboard and Management API.

Auth0 will notify you periodically if you haven't rotated your key in more than 365 days. Auth0 recommends that you rotate keys regularly to ensure that in case of a security breach you will be ready to take the actions needed.

Additional application signing certificates links are as follows:

We use the application signing key to sign assertions that are sent to applications. These assertions may include ID tokens, access tokens, SAML assertions, and WS-Fed assertions. Note that these keys are different from those used to sign interactions with connections, including signing SAML requests to Identity Providers (IdPs) and encrypting responses from IdPs.

By default, SAML assertions for IdP connections are signed, which we recommend. To get public keys you can use to configure the IdP, see SAML Identity Provider Configuration: Signed Assertions.

The rotation and revocation process supports your personal preferences and promotes a graceful transition for your application. If you prefer to update your application first, then rotate and revoke your key, you may do that. Alternatively, if you prefer to rotate your key, and then update your application and revoke your old key, you may also do that.

Available keys include:

  • Currently used: Key that is currently being used to sign all new assertions.

  • Previously used: Key that was previously used, but has been rotated out. Assertions that were generated with this key will still work.

  • Next in queue: Key that is queued and will replace the current key when the application signing key is next rotated.

Always test signing key rotation on a development tenant before rotating application signing keys in production.

Limitations

Rotating your signing key will be subject to a smaller rate limit than other API endpoints. To learn more, read Management API Rate Limits.

Learn more