> ## Documentation Index
> Fetch the complete documentation index at: https://auth0.com/llms.txt
> Use this file to discover all available pages before exploring further.

> Describes the difference between confidential and public application types.

# Confidential and Public Applications

According to the [OAuth 2.0 specification](https://tools.ietf.org/html/rfc6749#section-2.1), applications can be classified as either confidential or public. The main difference relates to whether or not the application is able to hold credentials (such as a <Tooltip tip="Client ID: Identification value given to your registered resource from Auth0." cta="View Glossary" href="/docs/glossary?term=client+ID">client ID</Tooltip> and secret) securely. This affects the type of authentication the applications can use.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Confidential/public and first-party/third-party are independent classifications. Confidential or public describes the application's authentication capability (whether it can hold a secret). First-party or third-party describes the trust relationship (who owns and operates the application). To learn more, read [First-Party and Third-Party Applications](/docs/get-started/applications/first-party-and-third-party-applications).
</Callout>

When you create an application using the Auth0 Dashboard, Auth0 will ask you what Auth0 application type you want to assign to the new application and use that information to determine whether the application is confidential or public.

To learn more, read [Check if Application is Confidential or Public](/docs/get-started/applications/confidential-and-public-applications/view-application-type).

## Confidential applications

Confidential applications can hold credentials in a secure way without exposing them to unauthorized parties. They require a trusted backend server to store the secret(s).

### Grant types

Confidential applications use a trusted backend server and can use grant types that require specifying their Client ID and <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> (or alternative registered credentials) for authentication when calling the Auth0 Authentication API [Get Token](https://auth0.com/docs/api/authentication#get-token) endpoint. Confidential applications can use Client Secret Post, Client Secret Basic, or [Private Key JWT](/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) authentication methods.

These are considered confidential applications:

* A web application with a secure backend that uses the [Authorization Code Flow](/docs/get-started/authentication-and-authorization-flow/authorization-code-flow), [Resource Owner Password Flow](/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow), or <Tooltip tip="Resource Owner: Entity (such as a user or application) capable of granting access to a protected resource." cta="View Glossary" href="/docs/glossary?term=Resource+Owner">Resource Owner</Tooltip> Password Flow with realm support
* A machine-to-machine (M2M) application that uses the [Client Credentials Flow](/docs/get-started/authentication-and-authorization-flow/client-credentials-flow)

### ID tokens

Because confidential applications are capable of holding secrets, you can have <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> issued to them that have signed in one of two ways:

* Symmetrically, using their client secret (`HS256`)
* Asymmetrically, using a private key (`RS256`)

## Public applications

Public applications **cannot** hold credentials securely.

### Grant types

Public applications can only use grant types that do not require the use of their client secret. They can't send a client secret because they can't maintain the confidentiality of the credentials required.

These are public applications:

* A native desktop or mobile application that uses the [Authorization Code Flow with PKCE](/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)
* A JavaScript-based client-side web application (such as a single-page app) that uses the [Implicit Flow](/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post) grant

### ID tokens

Because public applications are unable to hold secrets, [ID tokens](/docs/secure/tokens/id-tokens) issued to them must be:

* Signed asymmetrically using a private key (`RS256`)
* Verified using the public key corresponding to the private key used to sign the token

## Learn more

* [Check if Application is Confidential or Public](/docs/get-started/applications/confidential-and-public-applications/view-application-type)
* [First-Party and Third-Party Applications](/docs/get-started/applications/first-party-and-third-party-applications)
* [Third-Party Applications](/docs/get-started/applications/third-party-applications)
* [User Consent and Third-Party Applications](/docs/get-started/applications/third-party-applications/user-consent-and-third-party-applications)