<commit_before># Core Concepts: Applications

An application is one of the core concepts in Auth0, which is why it's important to know how this relates to your applications and the impact this will have on auditing, authorization, billing, ...

> Depending on the concepts or technologies you're working with, an application might also be referred to as a **client** or a **relying party**.

## Applications in Auth0

Let's start by looking at how applications are represented in Auth0 and how this relates to other core concepts like Connections and Rules.

### Settings

![](//cdn.auth0.com/docs/img/applications-callback-settings.png)

The application's settings contain the following information:

- **Name of the application**: Canonical name of your application which you'll see in the portal, emails, logs, ...
- **Client ID (read-only)**: This is the unique identifier for your application. This is the ID you'll use in your application when setting up authentication with Auth0.
- **Client Secret**: This secret will be used to sign and validate tokens which will be used in the different authentication flows. With this key your application will also be able to authenticate to some of the API endpoints (eg: to get an access token from an authorization code).
- **Allowed Callback Urls**: One or more urls of your application to which Auth0 can redirect after the user has authenticated.
- **Allowed Origins (CORS)**: If you want to use the Auth0 API from within the browser you'll need to add the urls of the applications running your javascript code to prevent Same-origin policy errors.
- **JWT Expiration**: The expiration in seconds of the access tokens that will be handed out by Auth0.
- **Use Auth0 instead of the IdP to do Single Sign On**: If this option is enabled Auth0 won't need to redirect users to the identity provider (Facebook, ADFS, ...) if the user has authenticated before and hasn't logged out or his session hasn't expired.

### Addons

![](//cdn.auth0.com/docs/img/applications-addon-types.png)

Addons are extensions associated with applications and are typically used in 2 different scenarios:

* **Accessing external APIs**: using the delegation endpoint an access token for the application can be exchanged for an access token to a third party service (like [Salesforce](server-apis/salesforce), Amazon, Azure, Firebase, ...).
* **Integrating with applications using SAML2/WS-Federation**: enables authentication through Auth0 for applications that support SAML2/WS-Federation like Dropbox, SharePoint, ... The most popuplar SaaS applications with SAML support are already covered as recipes that will automatially configure the SAML2/WS-Federation addon (in the dashboard under [Third-party applications](https://manage.auth0.com/#/externalapps)). By adding the addon on an application you can configure every aspect of the SAML2/WS-Federation integration, allowing you to integrate with any custom/third-party application that we haven't covered yet.

![](//cdn.auth0.com/docs/img/applications-third-party-overview.png)

### Connections

![](//cdn.auth0.com/docs/img/applications-connections-example.png)

On application level we are able to choose which connections are enabled, which is useful if an organization is building applications for different audiences. A timesheet application might be for employees only, so we'll want to restrict this to Active Directory authentication. But a customer facing application might have support for Google, Microsoft Accounts, different ADFS connections, ...

### Rules

![](//docs.google.com/drawings/d/16W_hTS_u2CeDFXkD2PlfituFl7b74EQ6HE_XYn3TdD0/pub?w=891&h=283)
<commit_msg>Fixed other typos<commit_after># Core Concepts: Applications

An application is one of the core concepts in Auth0, which is why it's important to know how this relates to your applications and the impact this will have on auditing, authorization, billing, ...

> Depending on the concepts or technologies you're working with, an application might also be referred to as a **client** or a **relying party**.

## Applications in Auth0

Let's start by looking at how applications are represented in Auth0 and how this relates to other core concepts like Connections and Rules.

### Settings

![](//cdn.auth0.com/docs/img/applications-callback-settings.png)

The application's settings contain the following information:

- **Name of the application**: Canonical name of your application which you'll see in the portal, emails, logs, ...
- **Client ID (read-only)**: This is the unique identifier for your application. This is the ID you'll use in your application when setting up authentication with Auth0.
- **Client Secret**: This secret will be used to sign and validate tokens which will be used in the different authentication flows. With this key your application will also be able to authenticate to some of the API endpoints (eg: to get an access token from an authorization code).
- **Allowed Callback Urls**: One or more urls of your application to which Auth0 can redirect after the user has authenticated.
- **Allowed Origins (CORS)**: If you want to use the Auth0 API from within the browser you'll need to add the urls of the applications running your javascript code to prevent Same-origin policy errors.
- **JWT Expiration**: The expiration in seconds of the access tokens that will be handed out by Auth0.
- **Use Auth0 instead of the IdP to do Single Sign On**: If this option is enabled Auth0 won't need to redirect users to the identity provider (Facebook, ADFS, ...) if the user has authenticated before and hasn't logged out or his session hasn't expired.

### Addons

![](//cdn.auth0.com/docs/img/applications-addon-types.png)

Addons are extensions associated with applications and are typically used in 2 different scenarios:

* **Accessing external APIs**: using the delegation endpoint an access token for the application can be exchanged for an access token to a third party service (like [Salesforce](server-apis/salesforce), Amazon, Azure, Firebase, ...).
* **Integrating with applications using SAML2/WS-Federation**: enables authentication through Auth0 for applications that support SAML2/WS-Federation like Dropbox, SharePoint, ... The most popular SaaS applications with SAML support are already covered as recipes that will automatically configure the SAML2/WS-Federation addon (in the dashboard under [Third-party applications](https://manage.auth0.com/#/externalapps)). By enabling the addon for an application you can configure every aspect of the SAML2/WS-Federation integration, allowing you to integrate with any custom/third-party application that we haven't covered yet.

![](//cdn.auth0.com/docs/img/applications-third-party-overview.png)

### Connections

![](//cdn.auth0.com/docs/img/applications-connections-example.png)

On application level we are able to choose which connections are enabled, which is useful if an organization is building applications for different audiences. A timesheet application might be for employees only, so we'll want to restrict this to Active Directory authentication. But a customer facing application might have support for Google, Microsoft Accounts, different ADFS connections, ...

### Rules

![](//docs.google.com/drawings/d/16W_hTS_u2CeDFXkD2PlfituFl7b74EQ6HE_XYn3TdD0/pub?w=891&h=283)

{'fraction_non_alphanumeric': 0.07445792990590482, 'fraction_numerical': 0.009818628119459976, 'mean_word_length': 4.825258141382049, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3166588', 'n_tokens_mistral': 1925, 'n_tokens_neox': 1774, 'n_words': 960}