Security Controls for Third-Party Applications

Auth0 enforces enhanced security controls for third-party applications to ensure:

Protocol-level security: Align with OAuth 2.1 best practices 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. This prevents authorization code interception attacks.
Supported grant types: authorization_code, refresh_token, and client_credentials.
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 to access any API, regardless of the API’s access policy.

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. Third-party applications cannot be granted access to system APIs such as the Management API or My Account API.

Scope shaping in Actions

Use api.transaction.* methods to modify scopes in Actions without bypassing the client grant, RBAC, or consent. Auth0 evaluates the final target set after all Actions finish. api.accessToken.addScope() is not supported for strict third-party applications because it bypasses those controls. To learn more, read Handling Scopes in Actions.

Machine-to-machine (Client Credentials)

Third-party applications support the client_credentials grant type for machine-to-machine access. This enables backend partner integrations and server-to-server API access without user involvement. Requirements and constraints:

Client type: The application must be a confidential client (token_endpoint_auth_method must not be none).
Organizations: Supported. To learn more, read Organizations.
Not available for applications created through Dynamic Client Registration or CIMD.

Extensibility:

Actions with the credentials-exchange trigger execute as usual for machine-to-machine access flows.

Organizations

Third-party applications support Organizations for both user flows and machine-to-machine access. Access is opt-in:

User flows (Authorization Code): The Organization must opt in via third_party_client_access: allow, and the connection used for login must be promoted to the domain level. If either is missing, Auth0 returns invalid_request.
Machine-to-machine (Client Credentials): allow_any_organization is not available. Each Organization must be authorized through an explicit organization_client_grant.

To set this up, read Configure Organizations access.

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`, `refresh_token`, or `client_credentials`
`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 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 and MCP 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:

{% 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.

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.
Hooks (credentials-exchange)	Not supported. Tenants with an active `credentials-exchange` Hook will receive an error. Migrate to Actions for `credentials-exchange` extensibility.
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.
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.

Quickstarts

Auth0 Overview

Configure Auth0

Applications

Security Controls for Third-Party Applications

OAuth 2.1 standards

Explicit API authorization

Scope shaping in Actions

Machine-to-machine (Client Credentials)

Organizations

Restricted client configuration

Client ID format

Refresh token settings

Redirect protection

`/authorize` parameter validation

Backward compatibility

Features not supported

Learn more

​OAuth 2.1 standards

​Explicit API authorization

​Scope shaping in Actions

​Machine-to-machine (Client Credentials)

​Organizations

​Restricted client configuration

​Client ID format

​Refresh token settings

​Redirect protection

​/authorize parameter validation

​Backward compatibility

​Features not supported

​Learn more

OAuth 2.1 standards

Explicit API authorization

Scope shaping in Actions

Machine-to-machine (Client Credentials)

Organizations

Restricted client configuration

Client ID format

Refresh token settings

Redirect protection

`/authorize` parameter validation

Backward compatibility

Features not supported

Learn more