Biometric authentication

Start here

This guide presents a technical overview of Entrust's biometric authentication solutions, available for integration through Workflow Studio.

Introduction

Studio workflows can be configured to include authentication tasks to enroll and authenticate users with the facial biometrics from a live photo capture, a motion capture or an identity document. This authentication can be done concurrently during an identity verification onboarding workflow, or at a later stage using previously-enrolled facial biometrics stored either on a user's device, or on your infrastructure, helping to protect you and your users from account takeover at high-risk moments (such as password reset).

Authentication with on-device storage

Authentication on-device involves authenticating a user by comparing their newly-captured biometrics with a reference biometric stored securely on the user's device during enrollment.

There are two main use cases for authentication with on-device storage:

• an onboarding workflow that verifies the identity of a user through a document and biometrics check before storing the encrypted biometric data on their device
• a standalone authentication workflow that verifies that the biometric data stored on a user's device matches against newly-captured facial biometrics

In order to assist integration, two workflow templates are available for these use cases in the Studio Workflow Builder. These templates are documented below.

Document and Motion with on-device storage

To concurrently onboard an end user and store their encrypted biometric data, the Studio workflow must contain a Document capture task and Document report task for document verification, as well as a Face capture: Motion task for a liveness check.

During this onboarding phase, the user's biometric data (processed from the document and motion capture) is symmetrically encrypted to generate a biometric token. In Studio, this non-interactive operation is performed by an Enroll biometrics task.

At this stage, the user's biometric data (generated by the Enroll biometrics task) is then securely stored on the user's device. In Studio, this non-interactive operation is performed by a Store on-device biometrics task.

The data is referred to as an encrypted biometric token, and is symmetrically encrypted before it is provided for storage. The encryption ensures:

• Confidentiality: Biometric data cannot be accessed by unauthorized parties
• Integrity: Data remains unaltered during transmission and storage

In order to uniquely identify a user, a customer_user_id must be set during workflow run creation. This customer user ID is an identifier that uniquely identifies your end user, regardless of the workflow applicant. It will default to the applicant ID if not specified at workflow creation.

During authentication, Entrust will verify the user's identity by comparing the newly-captured user's biometrics with the encrypted biometric token previously stored on the user's device.

A Document & Motion with on-device storage workflow

Standalone authentication with on-device storage

To authenticate an already-registered user, an encrypted biometric token previously stored using the Store on-device biometrics task must be retrieved from the user's device. In Studio, this is done by adding a Retrieve on-device biometrics task to a workflow. The retrieved encrypted biometric token is used to verify a user's identity by comparing it against the newly-captured user's biometric media.

To ensure successful authentication, the same customer_user_id assigned during registration for a specific user must be used during authentication when initializing a workflow run. If a different customer_user_id is used, the system will not be able to locate the encrypted biometric token, and the Retrieve on-device biometrics task will fail.

If you used the cross-device flow to generate the encrypted biometric token, make sure this option is also enabled when adding the Retrieve on-device biometrics task. Otherwise, the system won't be able to access the token on the device, and the task will fail.

Retrieving previously-enrolled biometrics for authentication

Authentication on customer infrastructure

As an alternative to storing encrypted biometric data on a user's device, you may choose to store the encrypted biometric token in your own secure server, whereby the encrypted biometric token is delivered to you by means of a webhook.

Similar to on-device storage, there are two main use cases for authentication when storing tokens on your own infrastructure:

• an onboarding workflow that verifies the identity of a user through a document and biometrics check before passing the encrypted biometric data via a webhook to your infrastructure
• a standalone authentication workflow that verifies that the biometric data from your infrastructure matches against newly-captured facial biometrics

In order to assist integration, two workflow templates are available for these use cases in the Studio Workflow Builder. These templates are documented below.

Document and Motion on customer infrastructure

To concurrently verify an end user's identity and store their encrypted biometric data on your infrastructure, the Studio workflow must contain a Document capture task and Document report task for document verification, as well as a Face capture: Motion task for a liveness check.

During this onboarding phase, the user's biometric data (processed from the document and motion capture) is symmetrically encrypted to generate a biometric token. In Studio, this non-interactive operation is performed by an Enroll biometrics task.

The encrypted biometric token is returned to your infrastructure by means of a webhook. For the webhook to contain the encrypted biometric data, the token must be configured as a workflow output. This must be configured as custom output data of semantic type Encrypted biometric token. The integrator must then set up a webhook for our system to return the encrypted biometric token that is generated from the original media back to your infrastructure.

Authenticate biometrics: Motion

For standalone authentication, an Authenticate biometrics: Motion task must be added to a Studio workflow to verify the user's identity by comparing the newly-captured biometrics (originating from a motion capture) with the encrypted biometric token stored on your infrastructure.

Authentication using biometric data stored on customer infrastructure

One of the inputs to the Authenticate biometrics: Motion task is the encrypted biometric token from a previous registration. It must be configured as custom input data of semantic type Encrypted biometric token.

You can later use this when creating a workflow run via the API by adding the custom input in the request body:

1$ curl -X POST https://api.eu.onfido.com/v3.6/workflow_runs \
2  -H 'Authorization: Token token=<YOUR_API_TOKEN>' \
3  -H 'Content-Type: application/json' \
4  -d '{
5  "workflow_id": "<WORKFLOW_ID>",
6  "applicant_id": "<APPLICANT_ID>",
7  "customer_user_id": "<CUSTOMER_USER_ID>",
8  "custom_data": {
9    "encrypted_biometric_token": {
10      "type": "encrypted_biometric_token",
11      "value": "<ENCRYPTED_BIOMETRIC_TOKEN>"
12    }
13  }
14}'

The workflow outputs a report result similar to a Facial similarity: Motion report task, wherein a conditional node may be configured to pass or fail the authentication attempt.

To ensure successful authentication, the same customer_user_id assigned during registration for a specific user must be used during authentication when initializing a workflow run. If a different customer_user_id is used, the validation of the encrypted biometric token will fail.

Authentication for existing users on your platform

Workflow Studio also allows for the authentication of users you may have previously onboarded and verified in the past onto your platform. If that's the case, Entrust offers the ability to enroll biometrics from a given media (e.g., motion capture, live photo or document) you might have on file for those users. Afterwards, you will want to run Authentication slightly differently, leveraging custom input data for the encrypted biometric token from that enrollment originating from the motion capture, live photo or document, and which will have to be passed with every subsequent authentication.

In order to assist your integration, Entrust has made available three workflow templates in the Studio Workflow Builder:

• Enrollment with customer infrastructure storage from a motion capture: a registration workflow that takes in a motion capture to generate an encrypted biometric token to be passed via a webhook to your infrastructure
• Enrollment with customer infrastructure storage from a live photo: a registration workflow that takes in a live photo to generate an encrypted biometric token to be passed via a webhook to your infrastructure
• Enrollment with customer infrastructure storage from a document photo: a registration workflow that takes in a document to generate an encrypted biometric token to be passed via a webhook to your infrastructure

Please note: In the case of enrollment from a document photo, when multiple document photos are uploaded for the same applicant, the system processes documents in order of upload without considering the side property. Consequently, the encrypted biometric token may be generated from a different document than the one used for a document check.

Media as enrollment custom workflow input data

In order to generate an encrypted biometric token from a supported media you have on file for a given user, the integrator must configure their registration workflow (e.g., Enrollment with customer infrastructure storage from a motion capture) to provide an input referencing a previously-recorded motion capture. This can either be an existing motion capture, live photo or identity document recorded via our SDK, or a previous live photo or identity document capture submitted via our API.

Please note: If you do not use the Entrust Identity Verification SDK or include a capture task in your workflow, you must provide location for every applicant. Where required, you must also collect and provide the end user's consent. If you do not, all tasks will fail with a validation error.

For configuring the webhook, please refer to the guide to Set up your webhook.