Measures Against Application Impersonation

Native applications use the Authorization Code Flow with PKCE authentication flow and employ a redirect_uri to return control to an application after login. After the URI loads in the device’s browser, the mobile app automatically opens to allow the user to continue their journey.

Historically, mobile applications used custom URI schemes (e.g., com.mycompany.myapp://oauth2redirect). However, custom URI schemes pose a risk as more than one application on the device can register the same scheme. Mobile OSs do not include any built-in mechanisms to ensure the application receiving the redirect is the intended one. In this scenario, malicious apps impersonate legitimate ones and receive the authorization response (including tokens) without user awareness, especially if single sign-on (SSO) is active due to the existence of a previous legitimate session, in which user interaction is not required.

Applications running on a local machine (e.g., desktop apps, CLIs) use the loopback interface for callbacks (e.g., http://127.0.0.1:51089/callback or http://localhost:61024/callback) are similarly at risk. In this case, another application on the same machine could listen on the same port to intercept the response.

We refer to both custom URI schemes and loopback URIs as Non-Verifiable Callback URIs because the authorization server cannot verify the receiving application in either scenario.

Modern mobile OSs support claimed HTTPS URIs, which allow you to associate a website domain that you control with your mobile app. Claimed HTTPS URIs are known as:

• Universal Links on iOS

• App Links on Android

Using claimed HTTPS URIs ensures that only your application handles the associated callback URL, protecting against unauthorized access to sensitive authentication data.

Auth0 cannot verify the legitimacy of the application receiving the authentication transaction results if:

• Your application is unable to support claimed HTTPS URIs due to required compatibility with older mobile OS versions

• Your application is a desktop or CLI application

As defined in the OAuth2 for Native Apps specification, Auth0 provides a mechanism to show a confirmation prompt to the user. This allows users to confirm that the application receiving the authentication result is the one they intended to access. When a custom URI scheme is in use, the user is prompted to verify the application on each authentication transaction.

The confirmation screen displays when:

1. The redirect_uri present in the request uses a custom URI scheme (i.e. not https://...).

2. The user has not been prompted with any other screen in the current login transaction (such as when a consent screen is shown for third-party applications, or when MFA is required).

In these cases, the end user is presented with a confirmation prompt.

The confirmation prompt uses your custom branding and configurations defined for existing consent screens used for third-party applications. To learn more, review the Prompts section of Customize Universal Login Page Templates.

You can configure the confirmation prompts in the following ways. Note that application-level settings take precedence over the global tenant-level setting. Application-level

1. Navigate to Auth0 Dashboard > Applications > Application Settings > Advanced > OAuth.

2. Scroll to the Non-Verifiable Callback URI End-User Confirmation setting.

3. Enable the toggle to activate the prompt or disable the toggle to deactivate the prompt.

   

Global

1. Navigate to Auth0 Dashboard > Settings > Advanced.

2. Find the Non-Verifiable Callback URI End-User Confirmation setting.

3. Enable the toggle to deactivate the prompt or disable the toggle to activate the prompt.