Guides & tutorials
Guides & tutorials
Security and UX are no longer at odds with each other on user authentication flows. Adaptive forms have begun to be used in combination with user authentication and risk scoring systems to create more secure and frictionless flows.
In this post, we show you how to build a risk-based and multi-factor authentication login flow with Arengu and your own API, that is compatible with any tech stack.
To build this use case in a few minutes you just need:
A two-step form, in which the step 2 will only be displayed if the user is considered risky.
The first step of the form will be connected to a flow that evaluates the user's risk level and, if it is considered risky, it will generate and send a temporary code by email, which will be requested and verified in the second step. If not, it will directly log the user in.
Let's check how to set it up with Arengu!
Go to the form editor and create a two-step form from scratch or select the login form template. Both options are valid. It must include the following steps and fields:
Then, activate the IP collection checkbox in the Settings tab and go to the Flows tab to create a new flow for each form step, by clicking on the corresponding + button. If you have used the login form template, you can delete or edit the flows associated by default.
Once you have created the form and the flows, publish the changes.
To make form step 1 work properly, we need to create and build a flow with this structure:
This flow will perform the following operations:
The first action in this flow is an HTTP request, which will check if the user is registered and if the credentials are valid. The settings for this action will vary according to your API but, in our case, they would be:
<pre class="code">
{
"sub": "{{input.body.email}}",
"auth_type": "password",
"password": "{{input.body.password}}"
}
</pre>
Then, include an If/then condition action to check the response of the HTTP request on the credentials and build two branches.
The settings of this If/then condition action are as follows:
For the responses that have not been successful, include an Input value mapping action and Show error message actions in the False branch.
The Input value mapping action will allow you to list the API error codes and configure a different message for each of them, as you can see in the image. To set up this action:
To display these error messages in the form, simply reference the {{inputValueMapping_login.result}} variable in the Show error message action.
If credentials are valid, we will make a GET HTTP request to the risk scoring service. The settings for this action would be:
The user's IP variable will appear in the variable selector if you have activated the IP collection option in the form settings and if you have executed this flow at least once. If you have not done this, go back to the form edition page, activate the IP collection option in the Settings tab, publish the change, click on the Preview button and execute the form.
As we did before, include an If/then condition action after the HTTP request to manage its response and create two branches. The settings of this action are as follows:
If the score is below 70 points, we will log the user in using a Submit the form action with these settings:
If the user's score is considered risky, we will ask for the second authentication factor but, first, we must save authentication data to recall it in the next flow. For this, add a Store state variable action with this settings:
Once the authentication data is stored, include a Generate one-time password action and reference the {{input.body.email}} variable from the form in it.
Then include one of the messaging native actions to send the OTP by email or sms. In this case, we will send it by email with Mailjet.
To set up this action:
Finally, include a Go to the next form step action and publish all the changes.
To make form Step 2 work properly, we need to create and build a flow with the structure that you can see in the image below, which will perform the following operations:
This flow will first include a Verify one-time password action with these settings:
Next, include an If/then condition action to handle the responses of the verification and create two branches with this condition:
We will also add a Show error message action to display a custom message in the form if the OTP is not correct, in the False branch.
In the True branch, we will configure the Submit the form action, enabling the Redirect to URL option and referencing the {{state.claim_url}} variable.
Just remember that, to recall this variable from the login HTTP request in this flow, we must have saved it in the previous one using the Store state variable action. Then publish all the changes and go back to the form edition page to open the preview and test it.
After testing your form and linked flows, you can see if everything has worked correctly in the Executions tab of each of the flows. Here you can check the inputs, outputs and errors of each of the actions in each execution to fix any possible bugs.
Do you want to try it by yourself? Sign up free or book a demo with our team. Still not sure about it? Take a look at the most common use cases.
Arengu allows you to build all your user flows connected to your current stack, and avoids coding all the UI, complex integrations, validations or logic from scratch. Try it for free and start building faster and scaling your application needs as they grow.