When you select our recommended  (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 , , assertions, and 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  (JWT). A JSON web key set (JWKS) is a set of keys containing the public keys used to verify any JWT issued by the 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 . Auth0 recommends that you rotate keys regularly to ensure you will be ready for action in case of a security breach. Additional application signing certificates are listed below.
These links populate using your active tenant to provide you with accurate information. You must be logged in to auth0.com/docs with your tenant credentials to access these links.To sign in, select Log in to the top right. After logging in, you can switch between tenants by selecting your profile icon and choosing Switch tenant.
You can also retrieve this information for individual applications through the . To do so, navigate to the Settings page for a specific application. Then, expand the Advanced Settings and choose the Certificates tab.
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