> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Describes ways you can authenticate your application with Auth0 services.

# Application Credentials

Confidential applications, unlike public applications, can securely store credentials. When confidential applications request access or <Tooltip tip="ID Token: Credential meant for the client itself, rather than for accessing a resource." cta="View Glossary" href="/docs/glossary?term=ID+tokens">ID tokens</Tooltip> from the [token endpoint](https://auth0.com/docs/api/authentication#get-token), the application must authenticate with the <Tooltip tip="ID Token: Credential meant for the client itself, rather than for accessing a resource." cta="View Glossary" href="/docs/glossary?term=authorization+server">authorization server</Tooltip>. 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`](https://auth0.com/docs/api/authentication#authorize-application) endpoint.

To learn more about confidential applications versus public applications, read [Confidential and Public Applications](/docs/get-started/applications/confidential-and-public-applications).

## Application authentication methods

To get tokens from Auth0, your application must authenticate through the [Authentication API](https://auth0.com/docs/api/authentication). Auth0 supports the following ways your application can authenticate:

* **<Tooltip tip="Client Secret: Secret used by a client (application) to authenticate with the Authorization Server; it should be known to only the client and the Authorization Server and must be sufficiently random to not be guessable." cta="View Glossary" href="/docs/glossary?term=Client+Secret">Client Secret</Tooltip>:** A symmetrical authentication method. In Client Secret authentication, you use the Client Secret Auth0 generated when you created the application.
* **Private Key <Tooltip tip="JSON Web Token (JWT): Standard ID Token format (and often Access Token format) used to represent claims securely between two parties." cta="View Glossary" href="/docs/glossary?term=JWT">JWT</Tooltip>:** 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 <Tooltip tip="OAuth 2.0: Authorization framework that defines authorization protocols and workflows." cta="View Glossary" href="/docs/glossary?term=OAuth">OAuth</Tooltip>:** 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](https://www.rfc-editor.org/rfc/rfc6749#section-2.3). 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.

<Warning>
  To ​​improve your security posture, we recommend using the Private Key JWT authentication method.
</Warning>

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](/docs/get-started/applications/rotate-client-secret).

### Private Key JWT authentication

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Private Key JWT is available for customers on the Enterprise plan. To upgrade, contact [Auth0 pricing](https://auth0.com/pricing/).
</Callout>

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](http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer).

You can use the <Tooltip tip="Auth0 Dashboard: Auth0's main product to configure your services." cta="View Glossary" href="/docs/glossary?term=Auth0+Dashboard">Auth0 Dashboard</Tooltip> or Auth0 <Tooltip tip="Auth0 Dashboard: Auth0's main product to configure your services." cta="View Glossary" href="/docs/glossary?term=Management+API">Management API</Tooltip> to configure a tenant to use Private Key JWT. To learn more, read [Configure Private Key JWT Authentication.](/docs/get-started/applications/configure-private-key-jwt)

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](/docs/secure/application-credentials/generate-rsa-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](/docs/get-started/applications/configure-private-key-jwt). To learn more about building an assertion for Private Key JWT, read [Authenticate with Private Key JWT](/docs/get-started/authentication-and-authorization-flow/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. <Tooltip tip="Identity Provider (IdP): Service that stores and manages digital identities." cta="View Glossary" href="/docs/glossary?term=Identity+providers">Identity providers</Tooltip> 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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  To use Highly Regulated Identity features, you must have an Enterprise Plan with the Highly Regulated Identity add-on. Refer to [Auth0 Pricing](https://auth0.com/pricing/) for details.
</Callout>

[mTLS for OAuth](https://www.rfc-editor.org/rfc/rfc8705) authenticates requests to the authorization server using mutual TLS based on self-signed certificates or public key infrastructure (PKI). Read [Authenticate with mTLS](/docs/get-started/authentication-and-authorization-flow/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](/docs/customize/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](/docs/get-started/authentication-and-authorization-flow/authenticate-with-mtls) and [Set up your customer edge](/docs/get-started/applications/configure-mtls/set-up-the-customer-edge).

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  You can set up [mTLS endpoint aliases](/docs/get-started/applications/configure-mtls/configure-mtls-for-a-tenant#enable-mtls-endpoint-aliases) to use a specific subdomain for mTLS for OAuth.
</Callout>

To learn how to configure mTLS, read [Configure mTLS Authentication](/docs/get-started/applications/configure-mtls). 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](/docs/get-started/authentication-and-authorization-flow/authenticate-with-mtls#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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  mTLS also supports Sender Constraining or Token Binding to protect access tokens from attackers. To learn more, read [Configure Sender Constraining](/docs/secure/sender-constraining/configure-sender-constraining). Token Binding does not require previously registered application credentials such as a client certificate for use with mTLS.
</Callout>

### JWT-Secured Authorization Request (JAR)

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  To use Highly Regulated Identity features, you must have an Enterprise Plan with the Highly Regulated Identity add-on. Refer to [Auth0 Pricing](https://auth0.com/pricing/) for details.
</Callout>

[JWT-Secured Authorization Request (JAR)](https://datatracker.ietf.org/doc/rfc9101/) 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](https://auth0.com/docs/api/management/v2) 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](/docs/get-started/applications/configure-jar).

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)](/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar).

### Key and certificate registration

<Warning>
  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.
</Warning>

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](/docs/get-started/applications/configure-private-key-jwt) and [Configure JWT-Secured Authorization Requests](/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar).

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](/docs/get-started/applications/credentials).

## Learn more

* [Credential Settings](/docs/get-started/applications/credentials)
* [Authenticate with Private Key JWT](/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt)
* [Rotate Credentials](/docs/get-started/applications/rotate-credentials)
* [Configure Private Key JWT Authentication](/docs/get-started/applications/configure-private-key-jwt)
* [Authenticate with mTLS](/docs/get-started/authentication-and-authorization-flow/authenticate-with-mtls)