Risk-based and adaptive MFA authentication with Auth0 Signals

Introduction
Risk-based and adaptive MFA authentication with Auth0 Signals

Over the last years, the use of multi-factor authentication systems has become more frequent due to the increase in phishing and theft of credentials, especially from web services that rely solely on user IDs and passwords for access.

In the current context, it is clear that a simple ID + password is no longer secure, and that's why many web services are adding authentication factors to check users.

Difference between MFA and adaptive MFA

We call multi-factor authentication (MFA) any system that checks the user's identity during login processes or any other operation, requiring 2 or more of these factors:

  • One the user knows, such as the password, ID, PIN or an answer to a personal question, defined during the registration process.
  • Another one provided by the system, like a token or a one-time password.
  • An extra physical evidence, for example, a finger-print or facial recognition.

While security greatly increases, UX may be impaired if we ask for additional factors on every login or transaction, and that's why adaptive MFA arises.

Benefits of adaptive MFA

Unlike the non-adaptive version, AMFA consists of setting up the identity provider to automatically choose the right factor to require in each case or stage, depending also on the user’s profile and behavior.

This variation of MFA evaluates if there is enough evidence to allow the user to access a website or execute an operation, or if it's necessary to ask for more info. Measuring hundreds of aspects and taking into account the existing risk on each situation, AMFA asks for the most proper factor among the available.

Therefore it enhances security without harming UX, and when a user tries to access with stolen credentials, the login is still protected.

Setting up adaptive MFA with Arengu

So, let's see how to configure an adaptive MFA process with Arengu & Auth0's Signals service adding a second layer of authentication based on the user's risk. This is a simple example, but you can really refine it as far as your needs, your imagination, or your access to third parties' APIs, can go.

Our example will consist of checking if the IP is reliable and, if it is not, to generate, send and request an OTP as a 2nd authentication factor. Let's have a look!

1. Create a 2-step form

First, create a form with two steps. Ask for credentials on the first one. The second step should ask for the OTP, and it will only be used if the IP's scoring is low.

2. Build a flow to check credentials on the first step

This flow will make a HTTP request to check login credentials and, if they are valid, make another one to connect with Auth0's Signals to get IP's score.

To set up the HTTP request action, simply go to your Auth0 Signals account, copy the API Key and paste it in this action, using the Authentication header.

Select also the GET method, and paste the URL below:

https://signals.api.auth0.com/v2.0/ip/{{input.meta.ip}}

You will use {{input.meta.ip}} to reference the IP of the user that submitted the form. Remember to enable it using the "Collect user IP on form submission" flag in your form's settings.

The API will return detailed information about the IP address from different sources, but we will focus on the score for this use case:

{
    "fullip": {
        "score": -1,
        ...
    }
}

Depending on the returned score, two different things could happen. If the confidence score is high (close to 1), the form will be submitted, considering that there is no risk.

If confidence score is low (close to -1), a one-time password will be generated and sent via email, and users will be redirected to the second step of the form, which will ask them for the OTP code. This way, we verify that the user truly has access to that email.

3. Build another flow to check the OTP code

Last, we simply need to create a flow to verify the generated OTP code and connect it with the second step of the form. Depending on whether the code is correct or not, show an error message or redirect the user setting session cookies (or just redirecting with a JWT in the URL). It's done!

Shape your authentication flow to your needs

This is a simple example, but the verification process can be refined as you want. For example, you can create a form with conditional logic to request more data from the user, or include progressive profiling enriching data with Clearbit.

Soon, you even will be able to combine them, displaying an autocomplete form with data from APIs and allow the user to indicate if they are correct or not. Arengu allows you to manage data from external services, and easily customize data privacy.


Do you want to try it by yourself?

Sign up free or schedule a demo with our team. Happy authentication! ;)

Author

Andrea L. Lozano

Social Media & Content Specialist.

View Comments
Next Post

Product Update — September 2020

Previous Post

HOTP vs TOTP: Differences and advantages