Skip to main content
Use this page to resolve common errors when integrating with third-party applications. For an overview of third-party application capabilities and restrictions, read Security Controls for Third-Party Applications.

​
Identify third-party application issues

If you encounter an error during an OAuth flow, check if the application is a third-party application:
  • Client ID prefix: Third-party applications have a client_id that starts with tpc_.
  • Tenant logs: In Auth0 Dashboard > Monitoring > Logs, filter by the application to review error events.

​
Common errors

​
unauthorized_client when requesting tokens

Cause: The third-party application does not have a client grant for the requested API. Third-party applications always require an explicit client grant, even when the API access policy is set to Allow All. Solution: Create a client grant for the application or configure default permissions for third-party applications. To learn more, read Application Access to APIs: Client Grants. 
curl --request POST \
  --url 'https://YOUR_DOMAIN/api/v2/client-grants' \
  --header 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{
    "default_for": "third_party_clients",
    "audience": "https://api.example.com",
    "scope": ["read:items", "write:items"],
    "subject_type": "user"
  }'

​
unauthorized_client even with “Allow All” API policy

Cause: The API’s access policy setting of Allow All applies only to first-party applications. Third-party applications always require an explicit client grant regardless of this setting. Solution: Configure a default permission for third-party applications or create a per-application client grant.

​
invalid_request on /authorize with unsupported parameters

Cause: Third-party applications enforce strict parameter validation on the /authorize endpoint. Parameters such as screen_hint, login_ticket, invitation, request (JAR), and request_uri (PAR) are not supported. Solution: Remove unsupported parameters from your authorization request. For the list of allowed parameters, read Security Controls for Third-Party Applications.

​
unsupported_response_type for id_token or token

Cause: Implicit flow (response_type=token or response_type=id_token) is not available for third-party applications. Solution: Use response_type=code with PKCE.

​
No ID token returned from /oauth/token

Cause: Third-party applications with enhanced security controls do not return ID tokens or process OIDC scopes (openid, profile, email) in this release. The token endpoint will return an access token but no id_token. Solution: Use API-scoped access tokens to retrieve the information your application needs. OIDC support for third-party applications is planned for a future release.

​
Grant type not supported

Cause: Only authorization_code and refresh_token grant types are supported. Grant types such as implicit, password, client_credentials, and urn:ietf:params:oauth:grant-type:device_code are not available. Solution: Update the application to use the Authorization Code Flow with PKCE.

​
Classic Login not working

Cause: Classic Login is not supported for third-party applications. Solution: Use Universal Login. Universal Login is the recommended login experience for all applications.

​
Client ID starts with tpc_

Cause: Third-party applications automatically receive a tpc_ prefix on their client ID for traffic classification. This is assigned at creation and cannot be changed. Solution: This is expected behavior. Update any client-side validation or database constraints to accommodate the longer client ID format.

​
Cannot change is_first_party or security mode

Cause: The security mode and application ownership are permanent design decisions set at creation. They cannot be changed afterward. Solution: Create a new application with the desired configuration. You cannot convert an existing application between first-party and third-party, or between security modes.

​
Email verification or password reset shows an error page

Cause: The application’s redirection_policy is set to open_redirect_protection, which prevents Auth0 from exposing application.callback_domain in email templates. Solution: Update your email templates with a Liquid conditional that provides a fallback for third-party applications: 
{% if application.callback_domain == '' %}
  https://YOUR_FALLBACK_DOMAIN
{% endif %}
{% if application.callback_domain != '' %}
  {{ application.callback_domain }}/result-page
{% endif %}
Alternatively, set redirection_policy to allow_always for trusted third-party applications created via the Dashboard or Management API. To learn more, read Security Controls for Third-Party Applications.

​
DCR client cannot access any API

Cause: Dynamically registered clients require default permissions configured before they can request tokens. Without default permissions, third-party DCR clients have no API access. Solution: Configure default permissions for third-party applications on each API the DCR clients need to access. To learn more, read Configure Third-Party Applications.

​
/userinfo returns error

Cause: The /userinfo endpoint is not available for third-party applications in this release. Solution: Use API-scoped access tokens to retrieve the information your application needs. OIDC support, including /userinfo, is planned for a future release.

​
/oauth/revoke works but logout endpoints do not

Cause: Logout endpoints (/v2/logout) are not available for third-party applications. Solution: Use POST /oauth/revoke to revoke refresh tokens. The application is responsible for clearing its own session state.

​
Connection not available for a third-party application

Cause: The connection is not promoted to the domain level. Third-party applications can only authenticate users through domain-level connections. Solution: Promote the connection to the domain level. To learn more, read Promote Connections to Domain Level.

​
Refresh token rotation causing issues

Cause: Refresh token rotation is enabled by default for public (SPA, Native) third-party applications, aligned with OAuth 2.1 requirements. Solution: Ensure your application handles rotating refresh tokens correctly, where each token exchange returns a new refresh token, and the previous one is invalidated. Admins can adjust rotation settings for manually created applications via the Dashboard or Management API.

​
Learn more