Skip to main content
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. 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.

​
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: Machine-to-machine access with Organizations is supported. An explicit organization client grant is required for each organization. The allow_any_organization option is not permitted for third-party applications. Default client grants for third-party applications cannot be used to configure organization_usage.
  • 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.

​
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: 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: 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:

​
/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:

​
Learn more