Confidential applications, unlike public applications, can securely store credentials. When confidential applications request access or from the token endpoint, the application must authenticate with the . During this request for tokens, the application provides credentials known by the application. Additionally, application credentials can also provide authenticity and integrity protection for request parameters sent to the /authorize endpoint. To learn more about confidential applications versus public applications, read Confidential and Public Applications.

​
Application authentication methods

To get tokens from Auth0, your application must authenticate through the Authentication API. Auth0 supports the following ways your application can authenticate:
  • : A symmetrical authentication method. In Client Secret authentication, you use the Client Secret Auth0 generated when you created the application.
  • Private Key : An asymmetric authentication method. In Private Key JWT, you generate a pair of keys, public and private, to use as credentials. You provide the public key and securely store the private key in your own systems without sharing it with Auth0.
  • mTLS for : An asymmetric authentication method. In mTLS for OAuth, you register a standard X.509 client certificate with Auth0. Then, you use the corresponding private key to securely establish the mTLS tunnel to send requests to your Auth0 tenant endpoints.

​
Client Secret authentication

Client Secret authentication is a symmetric authentication method included in the OAuth 2.0 specification. Client Secret authentication is the default authentication method in Auth0. This authentication method is supported by all existing applications and tooling. The Client Secret is a high-entropy value generated by Auth0 when you create an application and is known by both your application and Auth0. Your application authenticates by including the Client Secret in the request to the authorization server. Some security risks are associated with using Client Secret as a credential, especially for scenarios with higher security demands:
  • The secret used by the application is shared with Auth0.
  • The secret is sent over the network and could be intercepted in the case of man-in-the-middle attacks.
To ​​improve your security posture, we recommend using the Private Key JWT authentication method.
An application can have a single Client Secret. It is not possible to rotate the secret while you update your implementation with the new secret. To learn more, read Rotate Client Secrets.

​
Private Key JWT authentication

Private Key JWT is available for customers on the Enterprise plan. To upgrade, contact Auth0 pricing.
Private Key JWT authentication is an asymmetric authentication method that relies on private and public key pairs. To learn more, read JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants. You can use the or Auth0 to configure a tenant to use Private Key JWT. To learn more, read Configure Private Key JWT Authentication. In Private Key JWT, a request to the authorization server consists of two main steps:
  1. Configure public and private keys:
    1. Generate a key pair (one public key and one private key).
    2. Register the private key with the application making the authentication request and register the public key with the identity provider (IdP).
  2. Build an assertions for requests to the authorization server:
    1. Create a new assertion with specified claims in JWT format and sign it with the private key. Include this assertion as part of the request to the IdP.
    2. IdP validates the assertion using the public key.
To configure Private Key JWT for Auth0, read Configure Private Key JWT Authentication. To learn more about building an assertion for Private Key JWT, read Authenticate with Private Key JWT. There are some security benefits associated with using Private Key JWT:
  • The private key is not transmitted over the network and reduces the exposure risk of your application’s credentials. like Auth0 have no knowledge of the private key, and only applications that have access to the private key can create authentication requests.
  • The signed assertions have a short expiry time, limiting the window of opportunity for replay attacks.

​
mTLS for OAuth

To use Highly Regulated Identity features, you must have an Enterprise Plan with the Highly Regulated Identity add-on. Refer to Auth0 Pricing for details.
mTLS for OAuth authenticates requests to the authorization server using mutual TLS based on self-signed certificates or public key infrastructure (PKI). Read Authenticate with mTLS to learn more about how mTLS authentication works at Auth0. Auth0’s mTLS for OAuth initially targets customers in highly regulated sectors such as finance and healthcare that most likely already have mTLS deployments. To simplify customer adoption, the mTLS feature builds on custom domains and leverages the customer’s existing mTLS infrastructure to perform certificate provisioning and verification. To learn more about authenticating with mTLS and setting up your edge network, read Authenticate with mTLS and Set up your customer edge.
You can set up mTLS endpoint aliases to use a specific subdomain for mTLS for OAuth.
To learn how to configure mTLS, read Configure mTLS Authentication. Once you have set up your edge network and configured mTLS, your application needs to establish the mTLS tunnel to send requests to Auth0, as explained in Call the authorization server. In mTLS, the client certificate’s private key is not transmitted over the network, reducing the risk of exposing your application credentials. Identity providers like Auth0 do not have access to the private key. Only applications that have access to the private key can authenticate.
mTLS also supports Sender Constraining or Token Binding to protect access tokens from attackers. To learn more, read Configure Sender Constraining. Token Binding does not require previously registered application credentials such as a client certificate for use with mTLS.

​
JWT-Secured Authorization Request (JAR)

To use Highly Regulated Identity features, you must have an Enterprise Plan with the Highly Regulated Identity add-on. Refer to Auth0 Pricing for details.
JWT-Secured Authorization Request (JAR) is an OAuth2 protocol extension that enhances the security of authorization requests. It does so by using a JSON Web Token (JWT) request parameter to protect the integrity and confidentiality of the authorization request parameters. You can use the Auth0 Management API to configure JAR for your application. Auth0 implementation for JAR uses asymmetric cryptography, where you register the public key while securely storing the private key on your end. To learn more, read Configure JWT-Secured Authorization Requests. When using JAR, the client creates a JWT that includes the authorization request parameters, signs it with its private key, and sends it to the authorization server. The authorization server then verifies the signature using the client’s public key, and if the signature is valid, extracts the authorization request parameters from the JWT and processes the request as usual. To learn more about how to use JAR, read Authorization Code Flow with JWT-Secured Authorization Requests (JAR).

​
Key and certificate registration

You should generate a separate key pair for each type of credential usage. For example, do not reuse the same key pairs for both JAR and Private Key JWT Authentication.
You can register two public keys for an application at the same time. Auth0 handles verification against the proper key and allows you to rotate with no downtime. Once the old key has been removed or deactivated, all requests signed with the corresponding private key are invalidated. Note: Auth0 supports the following algorithms for application authentication and authorization request signing: RS256, RS384 and PS256. Please make sure to provide the appropriate keys for them. To learn more, read Configure Private JWT Authentication and Configure JWT-Secured Authorization Requests. Similarly, for mTLS client certificates, you can register two client X.509 certificates (self-signed or with the CA cert’s Subject DN) at the same time for an application. Auth0 handles verification against both client certificates, which allows you to rotate certificates with zero downtime.

​
Update application authentication method

You can update an application’s authentication method in the Auth0 Dashboard. To learn more, read Credential Settings.

​
Learn more