Verified simplifies multifactor authentication for B2B, B2C, and B2E environments by replacing OTP and KBAs with advanced facial biometrics to make Auth0 an even more flexible solution when adding authentication and authorization services to user applications for both consumer and workforce-related access.

The integration adds advanced facial biometrics as a second factor for user authentication and removes annoying one-time codes and concerns about changing or losing devices.

Getting started

Getting started with Verified for Auth0 can be accomplished in 4 easy steps:

Step 1: Sign up for an authID.ai Identity Verification platform account

Step 2: Create an Auth0 integration

1. Log in to the Identity Portal with user credentials from step 1.
2. Navigate to the blade marked Auth0 integration:

3. Create a new integration and adjust the options to suit user needs. The user can read more about the various options and their effects on the configuration options page. Be sure to at least have the Enabled toggle turned on.

CAUTION
Make sure to copy and securely store the autogenerated Integration Id and Session Secret parameters, as those can not be retrieved later.

Step 3: Add Verified Auth0 action

1. Login to Auth0 Dashboard.
2. Navigate to the Actions blade, select Library, and press + the Add Action button.
3. Start typing "Verified" in the search box to find the "Verified Biometric MFA" tile. Click on it to open the description page, then press Add Integration.
4. Review the permissions required by the integration to function and press Continue.
5. Configure the integration with the Session Secret and Integration ID obtained when creating the integration from step 2.

4. Step 4: Implement the action
   1. Navigate to the Actions blade, select Flows, and choose the Login Flow tile.
   2. Drag and drop the Verified action into the login flow.
   3. Apply the changes and confirm the action works in the application.

Video Walkthrough

Included a video walkthrough to guide you through step 3 and step 4 of this process:

Confirming action functionality

Once the Verified Integration is enabled in Auth0 Actions, the user login as usual to the application. If users choose to use the always-on request mode, users then be seamlessly redirected to the Verified experience for biometric enrollment. Once their biometry is captured and liveness is confirmed, the user's Verified account is created. the user can also elect to enroll a user on-demand after they have logged into the application, effectively deferring enrollment according to business logic.

The user can view a biometric credential by navigating to the Verified Enrolled Users section of the Identity Portal. Each user created within the Verified platform has an external ID as in the below screenshot below:

Notice that the External identifier is the same value as the user_id for a user in the Auth0 instance, demonstrated in the screenshot below. This is how the Verified platform can retrieve and compare a user's reference biometric credential.

Communication Sequence Diagram

Always-on vs. On-demand usage

Designed to be a part of Auth0 login flow, Verified CloudConnect for Auth0 is invoked as an Auth0 post-login action, as seen in the diagram above. When enabled, the user token is issued only if the user successfully passes the Verified biometric authentication process. This process can be invoked on-demand as business rules require, or included with every request requiring authentication.

Always-on Mode

When using the always-on request mode, any time a user attempts to perform a protected activity activates the Auth0 login flow, it prompts them to complete a biometric authentication challenge to verify their identity. This means that not only the user be prompted to present their biometrics when logging into the applications, but also any time a login check is required as defined by the business rules (e.g. changing account details, accessing sensitive documents, transferring funds, etc.). In the diagram below, this is indicated by the protected activity loop:

On-demand Mode

By contrast, the on-demand request mode allows you to define exactly when you present a biometric authentication challenge to check a user's identity. In the diagram below, there are two possible paths to follow when a user performs a protected activity. If your business logic dictates that a user needs to complete a biometric authentication challenge to proceed, it will follow the same process as the always-on request mode. Otherwise, you can choose when and how to issue the biometric authentication challenge based on business logic.

INFO
The critical difference is that you can opt to not require such a challenge. This could happen in any of the following example scenarios:

• A user already completed a biometric authentication challenge during this session (e.x. initial login to the application)
• The activity being performed is not considered high-risk or high-value (e.x. updating non-critical account information)
• User verified the user through other means (e.x. device authentication or passwordless login).

Calling Verified on-demand is simple. If you have set the Auth0 action to on-demand mode, you need to add or modify an additional query string called acr_values for the request to the /authorize endpoint. In order to request that Verified be used as the MFA mechanism and trigger the post-login-action, the query string should be set to acr_values=https://authid.ai/policies/multi-factor. For example, when using the authorization code flow for a user to log to the application or perform an otherwise protected activity, the user sends the request like so:

https\://YOUR_DOMAIN/authorize?  
        audience=https\://YOUR_DOMAIN/userinfo&  
        scope=openid&  
        response_type=code&  
        client_id=YOUR_CLIENT_ID&  
        redirect_uri=https\://YOUR_APP/callback&  
        state=YOUR_OPAQUE_VALUE&  
        acr_values=<https://authid.ai/policies/multi-factor>

Once a user completes this flow, the Auth0 token has a new claim added to it called https://authid.ai/claims/amr with a value of MFA. In the future, the user can check for the presence of this token claim and choose to conditionally perform a step-up challenge by adding the query string as shown above.

NOTE
Note that the action can function with any of the supported flows being used by your application.

TIP
This overview demonstrates how you can utilize the Verified action in your post-login workflow. If user need to change the request mode of the Verified action, visit the action installation page for more information.