> ## Documentation Index > Fetch the complete documentation index at: https://docs-dev.auth0-mintlify.app/llms.txt > Use this file to discover all available pages before exploring further. # Security Controls for Third-Party Applications > Learn about the security controls Auth0 enforces for third-party applications, including OAuth 2.1 and API authorization. Auth0 enforces enhanced security controls for third-party applications to ensure: * **Protocol-level security**: Align with [OAuth 2.1 best practices](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1) to ensure modern, secure authorization flows. * **Feature scope**: Ensure that external applications can only access resources you explicitly authorize. Auth0 regularly enhances security for third-party applications. Only features explicitly documented as supported should be used in production. Unsupported features may be modified or restricted without notice in future updates. ## OAuth 2.1 standards Third-party applications enforce modern OAuth standards: * **PKCE mandatory**: All authorization code flows require [Proof Key for Code Exchange](/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce). This prevents authorization code interception attacks. * **Supported grant types**: Only `authorization_code` and `refresh_token` are available. Additional grant types such as `client_credentials` are planned for a future release. * **Implicit and password grants not supported**: Legacy grant types that expose tokens in the browser URL or require direct credential handling are not available for third-party applications. ## Explicit API authorization Third-party applications always require a [client grant](/docs/get-started/applications/application-access-to-apis-client-grants) to access any API, regardless of the API's [access policy](/docs/get-started/apis/api-access-policies-for-applications). | **API access policy** | **First-party applications** | **Third-party applications** | | --------------------- | ---------------------------- | ---------------------------- | | Allow All | Access granted | Requires client grant | | Require Client Grant | Requires client grant | Requires client grant | | Deny | Access denied | Access denied | Third-party applications must have an explicit grant, even when an API is configured with an **Allow All** policy. You can configure per-application permissions or [default permissions for third-party applications](/docs/get-started/applications/application-access-to-apis-client-grants#default-permissions-for-third-party-applications). Third-party applications cannot be granted access to [system APIs](/docs/get-started/apis#system-apis) such as the Management API or My Account API. ## Restricted client configuration You can only configure a curated set of client properties for third-party applications. When new properties are added to Auth0, they are not available for third-party applications unless explicitly reviewed and added to the supported set. Key supported properties include: | **Property** | **Notes** | | --------------------------------------- | ------------------------------------------------------------ | | `name`, `description`, `logo_uri` | Basic metadata | | `callbacks` | Redirect URIs | | `allowed_origins`, `web_origins` | CORS and web\_message origins | | `grant_types` | Must be `authorization_code` or `refresh_token` | | `token_endpoint_auth_method` | Authentication method for the token endpoint | | `app_type` | Must be `regular_web`, `spa`, `native`, or `non_interactive` | | `client_metadata` | Custom key-value metadata | | `jwt_configuration.lifetime_in_seconds` | Access token lifetime (defaults to 3600) | | `jwt_configuration.alg` | Signing algorithm (must be `RS256`; `HS256` not supported) | | `refresh_token.*` | Rotation, expiration, leeway, lifetime settings | | `client_authentication_methods` | Private Key JWT (`private_key_jwt` only; no mTLS) | | `require_proof_of_possession` | DPoP configuration | | `redirection_policy` | Redirect behavior for error flows and email templates | For the complete list of supported properties, read the [Create a Client endpoint](https://auth0.com/docs/api/management/v2/clients/post-clients) in the Management API reference. ## Client ID format Third-party applications have a `client_id` with a `tpc_` prefix assigned at creation. This prefix enables Auth0 to classify and manage third-party application traffic separately, including rate limits for third-party applications. The security mode and application ownership are permanent design decisions: * `third_party_security_mode` cannot be changed after creation. * Third-party applications cannot be converted to first-party applications, and vice versa. ## Refresh token settings Third-party applications enforce secure refresh token settings: * **Expiration required**: Non-expiring refresh tokens are not available. Infinite idle lifetime is not available. * **Rotation enabled by default for public clients**: SPA and Native third-party applications have refresh token rotation enabled by default, aligned with the [OAuth 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1) and [MCP](https://modelcontextprotocol.io/specification/draft/basic/authorization) requirements. * **Configurable**: Admins can adjust rotation, leeway, and lifetime settings for manually created third-party applications. ## Redirect protection The `redirection_policy` property controls how Auth0 handles redirects for third-party applications. It accepts two values: | **Value** | **Behavior** | | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | `open_redirect_protection` (default for third-party apps) | Auth0 does not redirect to the app callback on authentication errors. The `application.callback_domain` variable is not exposed in email templates. | | `allow_always` | Standard redirect behavior. | Redirects without user interaction can be an attack vector for phishing when the redirect URI is controlled by an untrusted party (open redirect). Only set `redirection_policy` to `allow_always` for applications where the configured callback URIs are trusted. When `open_redirect_protection` is active: * Authentication errors display an error page instead of redirecting to the application. * Email templates (email verification, password reset, user blocked) will not have access to `{{ application.callback_domain }}`, so a fallback must be configured alongside any use of `{{ application.callback_domain }}`. For example: ```liquid wrap lines theme={null} {% if application.callback_domain == '' %} https://YOUR_FALLBACK_DOMAIN {% endif %} {% if application.callback_domain != '' %} {{ application.callback_domain }}/result-page {% endif %} ``` ## `/authorize` parameter validation Auth0 validates the parameters sent to the `/authorize` endpoint for third-party applications. Only standard OAuth 2.0 and OpenID Connect parameters are accepted. **Allowed parameters:** * `acr_values` * `audience` * `authorization_details` * `client_id` * `code_challenge` * `code_challenge_method` * `connection` * `correlation_id` * `display` * `dpop_jkt` * `ext-*` (custom parameters) * `login_hint` * `max_age` * `nonce` * `prompt` * `redirect_uri` * `resource` * `response_type` * `scope` * `state` * `ui_locales` **Not supported:** * `claims` * `id_token_hint` * `invitation` * `login_ticket` * `request` (JAR) * `request_uri` (PAR) * `screen_hint` Requests with unsupported parameters receive an `invalid_request` error. ## Backward compatibility Some tenants that were using third-party applications before April 2026 may have applications operating with different security settings for backward compatibility. To learn more, read [Permissive Mode for Third-Party Applications](/docs/get-started/applications/third-party-applications/permissive-mode). ## Features not supported The following features are not supported for third-party applications: | **Feature** | **Status** | | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **OIDC scopes and ID tokens** | Not supported. Planned for a future release. | | **`/userinfo` endpoint** | Not supported. | | **Auth0 system APIs** (Management API, MFA API, My Account API, My Orgs API) | Not supported. Third-party applications cannot access system APIs in user flows. | | **MFA during refresh token exchange** | Not supported. Refresh token transactions that trigger MFA will result in an error. | | **Rules** | Not supported. Tenants with active Rules will receive an error when a strict third-party application triggers a login flow. | | **Non-OAuth Authentication API endpoints** (`/dbconnections/*`, `/passwordless/*`) | Not supported. | | **Legacy endpoints** (`/delegation`, `/oauth/ro`) | Not supported. | | **SAML, WsFed** | Not supported. | | **Classic Login** | Not supported. Use [Universal Login](/docs/authenticate/login/auth0-universal-login). | | **PAR, CIBA, Device Code** | Not supported. Planned for a future release. | | **Logout endpoints** | Not supported. Use `POST /oauth/revoke` to revoke tokens. | | **Cross-origin authentication** | Not supported. | | **Backchannel logout** | Not supported. Planned for a future release. | | **Client ID import** | Not supported. | | **Wildcard subdomains in URLs** | Not supported. Callback URLs, allowed origins, and web origins must use exact URLs. | ## Learn more * [Third-Party Applications](/docs/get-started/applications/third-party-applications) * [Configure Third-Party Applications](/docs/get-started/applications/third-party-applications/configure-third-party-applications) * [Troubleshoot Third-Party Applications](/docs/get-started/applications/third-party-applications/troubleshooting) * [Application Access to APIs: Client Grants](/docs/get-started/applications/application-access-to-apis-client-grants) * [Permissive Mode for Third-Party Applications](/docs/get-started/applications/third-party-applications/permissive-mode)