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: 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 to access any API, regardless of the API’s access policy.
API access policyFirst-party applicationsThird-party applications
Allow AllAccess grantedRequires client grant
Require Client GrantRequires client grantRequires client grant
DenyAccess deniedAccess denied
Third-party applications must have an explicit grant, even when an API is configured with an Allow All policy. You can configure a per-application grant or a default third-party permission. Third-party applications cannot be granted access to 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:
PropertyNotes
name, description, logo_uriBasic metadata
callbacksRedirect URIs
allowed_origins, web_originsCORS and web_message origins
grant_typesMust be authorization_code or refresh_token
token_endpoint_auth_methodAuthentication method for the token endpoint
app_typeMust be regular_web, spa, native, or non_interactive
client_metadataCustom key-value metadata
jwt_configuration.lifetime_in_secondsAccess token lifetime (defaults to 3600)
jwt_configuration.algSigning algorithm (must be RS256; HS256 not supported)
refresh_token.*Rotation, expiration, leeway, lifetime settings
client_authentication_methodsPrivate Key JWT (private_key_jwt only; no mTLS)
require_proof_of_possessionDPoP configuration
redirection_policyRedirect 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:
ValueBehavior
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_alwaysStandard 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:
FeatureStatus
OIDC scopes and ID tokensNot supported. Planned for a future release.
/userinfo endpointNot 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 exchangeNot supported. Refresh token transactions that trigger MFA will result in an error.
RulesNot 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, WsFedNot supported.
Classic LoginNot supported. Use Universal Login.
PAR, CIBA, Device CodeNot supported. Planned for a future release.
Logout endpointsNot supported. Use POST /oauth/revoke to revoke tokens.
Cross-origin authenticationNot supported.
Backchannel logoutNot supported. Planned for a future release.
Client ID importNot supported.
Wildcard subdomains in URLsNot supported. Callback URLs, allowed origins, and web origins must use exact URLs.

​
Learn more