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

# Application Profiles

> Learn how to use Application Profiles to apply a consistent runtime configuration policy to dynamically registered CIMD applications in Auth0.

> [!WARNING]
>
> **The Application Profiles feature is in .**

Application Profiles let you define a runtime configuration policy that automatically applies to a group of applications in your tenant. This enables you to set consistent application settings such as refresh token lifetimes and [Organization](/docs/manage-users/organizations/organizations-overview.md) behavior without having to configure each application individually.

Application Profiles EA targets dynamically created [Client ID Metadata Document (CIMD)](/docs/get-started/auth0-overview/create-applications/cimd-overview) applications. Instead of being created manually through the Auth0 Dashboard or Management API, dynamic CIMD applications register themselves at runtime by pointing to a metadata URL. While the [CIMD standards](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document) include a defined set of parameters governing the OAuth 2.0 client behavior that can be specified in the metadata, they do not include Auth0-specific parameters, which would make all CIMD applications use the same defaults. Application Profiles complement the metadata by supplying values for Auth0-specific parameters.

Application Profiles EA only supports dynamically registered CIMD applications; [dynamically registered clients](/docs/get-started/applications/dynamic-client-registration.md) and [manually registered CIMD applications](/docs/get-started/auth0-overview/create-applications/register-applications-with-cimd.md) are not supported. To learn more, read [Limitations](#limitations).

## Use cases

Common use cases for Application Profiles include:

* **Dynamic CIMD applications**: Applications that register themselves at runtime by pointing to a metadata URL, thus lacking a manual creation step where tenant administrators would usually configure application settings.
* **Fleet management**: A single configuration controls a large number of applications.

## How it works

Application Profiles are defined by the tenant administrator by providing default values for clients governed by that profile. Auth0 evaluates Application Profiles at runtime on every authentication request, not when an application is created. This means:

* A profile applies retroactively to every matching application, including ones that were registered before the profile existed.
* If you update or delete a profile, the change takes effect within the 5-minute cache propagation window on the next authentication request, with no need to update individual applications.
* Application Profile settings are never written to the application record. They're merged into an in-memory configuration at the moment of the authentication request.

Auth0 caches Application Profile configuration for up to 5 minutes. After creating, updating, or deleting a profile, allow up to 5 minutes for the change to take effect across all authentication requests.

### What a profile can match

An Application Profile can only match dynamically registered CIMD applications (`external_metadata_type: cimd`, created by the client itself rather than a tenant admin). Applications created manually, including a manually-configured CIMD application, are not matched by a profile. If you create an application by hand, you already have direct, explicit control over every one of its settings, and a profile is never applied on top of that configuration.

### Only one profile per tenant

A tenant may have at most one Application Profile. Support for multiple profiles, with priority-based conflict resolution, is planned for a future release.

## Supported client settings

Application Profiles support the following client settings:

### Tokens

In Application Profiles EA, you cannot configure refresh token rotation behavior (`rotation_type`) through an Application Profile. It's determined automatically from each application's authentication method: public applications rotate refresh tokens by default, confidential applications do not.

| Setting | Description |
| - | - |
| Rotation Overlap Period | Time in seconds the most recently-used refresh token can be reused without triggering breach detection. Only applies to public dynamic (CIMD) applications, which use refresh token rotation; confidential dynamic (CIMD) applications are non-rotating. To learn more, read [Configure Refresh Token Rotation](/docs/secure/tokens/refresh-tokens/configure-refresh-token-rotation.md). |
| Set Idle Refresh Token Lifetime | To enable, set to **Expiring**. Always set to **Expiring** in the Auth0 Dashboard. |
| Idle Refresh Token Lifetime | Time in seconds that a refresh token can live unused, after which the refresh token expires and can no longer be used to get a new access token. To learn more, read [Configure Refresh Token Expiration](/docs/secure/tokens/refresh-tokens/configure-refresh-token-expiration.md). |
| Set Maximum Refresh Token Lifetime | To enable, set to **Expiring**. Always set to **Expiring** in the Auth0 Dashboard. |
| Maximum Refresh Token Lifetime | The maximum time in seconds a refresh token can live, after which, if the refresh token is not exchanged within the specified interval, the refresh token expires and can no longer be used to get a new access token. The Maximum Refresh Token Lifetime must always be greater than the Idle Refresh Token Lifetime. To learn more, read [Configure Refresh Token Expiration](/docs/secure/tokens/refresh-tokens/configure-refresh-token-expiration.md). |
| Require Sender Constraining | Set to **Not Required** or **Required**. To learn more, read [Sender Constraining](/docs/secure/sender-constraining.md). |

You must set both the Idle Refresh Token Lifetime and Maximum Refresh Token Lifetime together; you cannot override just one side of a dependent pair, since doing so could produce an invalid combination once merged with the application's own value or platform default.

### Login Experience

| Setting | Description |
| - | - |
| Types of Users | Define the type of users that will log in to this application. Set to **Individuals**, **Business Users**, or **Both**. To learn more, read [Configure the login experience of your application](/docs/manage-users/organizations/login-flows-for-organizations.md#configure-the-login-experience-of-your-application). |
| Login Initiation Prompt | Define how to initiate the login flow for this application's users. Set to **Prompt for Credentials**, **Prompt for Organization**, or **No Prompt**. To learn more, read [Configure the Login Flow for your application](/docs/manage-users/organizations/login-flows-for-organizations.md#configure-the-login-flow-for-your-application). |

## Manage Application Profiles

Manage Application Profiles using the Auth0 Dashboard or Management API.

**Auth0 Dashboard**

To create an Application Profile in the Auth0 Dashboard:

1. Navigate to **Applications > Application Profiles**.
2. Toggle on **Application Profile**.
3. In the **Settings** tab, enter the name for the Application Profile (required) and provide a description.
4. In the **Tokens** section, configure client settings related to refresh tokens.
5. In the **Login Experience** tab, configure how clients behave in relation to Organizations.

To delete the Application Profile, toggle it off.

**Management API**

Manage Application Profiles through the Management API. All operations require an access token with the relevant scope.

| Scope | Grants |
| - | - |
| `read:client_profiles` | Retrieve or list profiles |
| `create:client_profiles` | Create a profile |
| `update:client_profiles` | Update a profile |
| `delete:client_profiles` | Delete a profile |

### Create an Application Profile

To create an Application Profile, make a `POST` request to the `/api/v2/client-profiles` endpoint:

**Auth0 CLI**

Using the Auth0 CLI? If you haven't already, [set up and authenticate your CLI session](/docs/deploy-monitor/auth0-cli.md) before running this command.

```bash theme={null}
auth0 api post "client-profiles" \
  --data '{
    "name": "Dynamic Third-Party Applications",
    "description": "Default runtime policy for dynamically registered third-party clients",
    "apply_policy": {
      "external_metadata_type": "cimd",
      "external_metadata_created_by": "client"
    },
    "client_configuration": {
      "refresh_token": {
        "token_lifetime": { "default_value": 2592000 },
        "idle_token_lifetime": { "default_value": 1296000 },
        "leeway": { "default_value": 0 }
      },
      "organization_usage": { "default_value": "deny" },
      "organization_require_behavior": { "default_value": "no_prompt" },
      "organization_discovery_methods": { "default_value": ["email", "organization_name"] },
      "require_proof_of_possession": { "default_value": false }
    }
  }'
```

**cURL**

```bash wrap lines theme={null}
curl --request POST \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/client-profiles' \
  --header 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{
    "name": "Dynamic Third-Party Applications",
    "description": "Default runtime policy for dynamically registered third-party clients",
    "apply_policy": {
      "external_metadata_type": "cimd",
      "external_metadata_created_by": "client"
    },
    "client_configuration": {
      "refresh_token": {
        "token_lifetime": { "default_value": 2592000 },
        "idle_token_lifetime": { "default_value": 1296000 },
        "leeway": { "default_value": 0 }
      },
      "organization_usage": { "default_value": "deny" },
      "organization_require_behavior": { "default_value": "no_prompt" },
      "organization_discovery_methods": { "default_value": ["email", "organization_name"] },
      "require_proof_of_possession": { "default_value": false }
    }
  }'
```

`name` and `client_configuration` are required. `apply_policy` is also required, although currently it only accepts one value:

```json theme={null}
{ "external_metadata_type": "cimd", "external_metadata_created_by": "client" }
```

A successful request returns `201 Created` with the full profile object, and a `Location` header pointing to the new resource.

### Retrieve an Application Profile

To retrieve an Application Profile, make a `GET` request to the `/api/v2/client-profiles/{clientId}` endpoint:

**Auth0 CLI**

```bash theme={null}
auth0 api get "client-profiles/YOUR_PROFILE_ID"
```

**cURL**

```bash wrap lines theme={null}
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/client-profiles/YOUR_PROFILE_ID' \
  --header 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN'
```

Returns `200 OK` with the profile object, or `404 Not Found` if no profile exists with that ID.

### List Application Profiles

To list all Application Profiles, make a `GET` request to the `/api/v2/client-profiles` endpoint:

**Auth0 CLI**

```bash theme={null}
auth0 api get "client-profiles"
```

**cURL**

```bash wrap lines theme={null}
curl --request GET \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/client-profiles' \
  --header 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN'
```

If successful, Auth0 returns an array of client profile objects:

```json theme={null}
{
  "client_profiles": [
    {
      "id": "cpr_7Yw3kBnP4mQ8vX",
      "name": "Dynamic Third-Party Applications",
      "apply_policy": { "external_metadata_type": "cimd", "external_metadata_created_by": "client" },
      "client_configuration": { "..." },
      "created_at": "2026-01-15T10:30:00.000Z",
      "updated_at": "2026-05-11T14:22:00.000Z"
    }
  ],
  "next": "eyJpZCI6ImNwcl83..."
}
```

This endpoint supports checkpoint pagination.

### Update an Application Profile

To update an Application Profile, make a `PATCH` request to the `/api/v2/client-profiles/{clientId}` endpoint:

**Auth0 CLI**

```bash theme={null}
auth0 api patch "client-profiles/YOUR_PROFILE_ID" \
  --data '{
    "client_configuration": {
      "refresh_token": {
        "token_lifetime": { "default_value": 2592000 },
        "idle_token_lifetime": { "default_value": 604800 },
        "leeway": { "default_value": 30 }
      },
      "organization_usage": { "default_value": "allow" }
    }
  }'
```

**cURL**

```bash wrap lines theme={null}
curl --request PATCH \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/client-profiles/YOUR_PROFILE_ID' \
  --header 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{
    "client_configuration": {
      "refresh_token": {
        "token_lifetime": { "default_value": 2592000 },
        "idle_token_lifetime": { "default_value": 604800 },
        "leeway": { "default_value": 30 }
      },
      "organization_usage": { "default_value": "allow" }
    }
  }'
```

`PATCH` accepts a partial update at the top level; you only need to include the fields you're changing (`name`, `description`, `client_configuration`, `apply_policy`).

The parameters `client_configuration` and `apply_policy` must be submitted in full when included in a `PATCH` request. Partial updates to nested fields inside these objects are not supported. Any sub-fields you omit from the object are treated as not set on the profile (falling back to the governed application's own configuration), not left unchanged from the previous version.

A successful update returns `200 OK` with the full, updated profile object. Changes take effect within the 5-minute cache propagation window.

### Delete an Application Profile

To delete an Application Profile, make a `DELETE` request to the `/api/v2/client-profiles/{clientId}` endpoint:

**Auth0 CLI**

```bash theme={null}
auth0 api delete "client-profiles/YOUR_PROFILE_ID"
```

**cURL**

```bash wrap lines theme={null}
curl --request DELETE \
  --url 'https://YOUR_AUTH0_DOMAIN/api/v2/client-profiles/YOUR_PROFILE_ID' \
  --header 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN'
```

Returns `204 No Content`, whether or not a profile with that ID existed. Deleting a profile immediately removes its governance from every application that matched it — those applications revert to their own individually-configured settings (or platform defaults) on their next authentication request.

## Limitations

This is an Early Access release. The following limitations apply and are expected to be addressed in future releases:

* Only one Application Profile is allowed per tenant.
* Application Profiles apply only to dynamically registered CIMD applications. Manually created applications, including manually configured CIMD applications, are never matched.
* [Dynamic Client Registration (DCR)](/docs/get-started/applications/dynamic-client-registration.md) applications are not supported by Application Profiles in this release.
* There is no way to list which applications a given profile currently governs.
* There is no way to exempt (opt out) an individual application from an Application Profile that would otherwise match it.
* Refresh token settings applied by a profile do not distinguish between public and confidential applications; the same values apply to every governed application regardless of authentication method.

## Learn more

* [CIMD Overview](/docs/get-started/auth0-overview/create-applications/cimd-overview)
* [Register Applications with CIMD](/docs/get-started/auth0-overview/create-applications/register-applications-with-cimd.md)
* [Dynamic Client Registration](/docs/get-started/applications/dynamic-client-registration.md)
