Adding multi-factor authentication to your web application

Verifying the identity of a computer system or user is known as authentication. In simple words, it means determining if someone is who they say they are. For example, you can not get a boarding pass until the airline staff verifies your identity and the full ticket has been paid for. Similarly, you must enter the correct login credentials (username and password) to use your Facebook account.

What is multi-factor authentication?

In multi-factor authentication (MFA), you give two or more pieces of evidence to access a website, application, or service. Consider an online banking application. To transfer money, you log in with your password and then enter an OTPOne-time password that is valid for only one login session or transaction. before confirming the transaction. This way, the bank reduces the risk of unauthorized access to the user’s account.

MFA vs. 2FA

Requiring more than two different authentication methods would, in most cases, be downright irritating to users. Hence, using two factors is practiced widely, hence the term two-factor authentication (2FA). In simple words, 2FA is a type of MFA.

Choosing your authentication factors

To enable MFA in web applications, you can choose among two or more of the following factors:

• Knowledge factor: Something known to a user, for example, password, PIN, OTP, and security questions.

• Possession factor: Something possessed by a user, for example, a cell phone, card, hardware token, or email.

• Inherence factor: Something inherent to a user, for example, biometrics like a fingerprint or retina scan.

For example, to authenticate access to a corporate network, we can use the “knowledge+possession” factor. Employees will log in with their password and then receive a notification on their registered devices asking them to approve the login attempt. We can use the “knowledge+inherent” factor for different biometric solutions. For example, in a voice recognition system, users log in with their password and are prompted to speak a passphrase into a microphone.

Selecting an MFA service provider

You can either build your own authentication workflow or use a service provider known for its authentication services. Some popular MFA service providers include Auth0, Okta, SafeNet, SecureAuth, and Duo. MFA service providers offer pre-built integrations, which makes it easier to manage MFA across some popular business applications. The aforementioned service providers commonly provide built-in integrations with the following web-based technologies:

• Auth0: Node.js, ASP.NET, PHP, Python, Java, and Ruby

• Okta: .NET, Java, Node.js, Python, Ruby, and PHP

• SafeNet: .NET, Java, PHP, Python, and Node.js

• SecureAuth: Java, .NET, PHP, Node.js, and Python

• Duo: Python, Java, Node.js, PHP, and .NET

Before deciding, consider the pre-built integrations your web application might need. Not all integrations are available off the shelf. So, it is recommended that you look for a solution that supports custom integrations.

Admin controls and policies must be revisited when choosing an MFA solution. These providers allow configuring policies at different levels, e.g., per-application, per-user or per-group, and global level. Per-application and per-group policies enforce extra protections for applications that may be highly sensitive. On the other hand, global policies allow you to restrict which devices, browsers, and networks can access corporate accounts and which factors can be used to authenticate users/systems.

The reporting capabilities can help decide which solution works best for your application. Most MFA solutions provide detailed reports on authentication attempts, with information about the time, location, and devices. This can be extremely helpful in detecting malicious logins, enforcing compliance with security threats, and revoking access to unsecured devices or systems. 

The pricing model is also very essential. Here’s a tip: “Do count the total price of ownership and not just the initial setup cost.” For some low-cost onboarding MFA solutions, we may need to spend an additional fee on admin overhead, security, and maintenance. During research, look out for explicitly documented pricing models to avoid the problem of hidden charges. For example, for Auth0, the initial setup cost might appear low, especially if we start with the free tier or the lowest paid tier. However, integrating it into a custom web application might require significant development effort. This could mean hiring additional developers leading to increased labor costs. Also, if we need to increase security, upgrading to a plan with these features can substantially increase our costs.

Integrating MFA in web applications

Be prepared to update the existing authentication workflow (if any) to incorporate the additional steps required for MFA. Consider a one-step authentication scenario where a user enters the username and password to log in to the application. Follow the guide below to integrate the MFA login flow:

• Step 1: Update your application’s login page to allow for additional verification. This may include adding more fields or steps for users to enter their second authentication factor or more.

• Step 2: Verify the primary authentication credential(s) before the MFA step.

• Step 3: Prompt the user to provide the next authentication factor. The instructions and error messages must be clear and should not cause any confusion to the users. Display the available MFA methods in correspondence with the factor(s) you chose. For example:

  • Bad message: Authentication failed.

  • Good message: The password is incorrect; please try again.

• Step 4: Verify the second authentication factor provided by the user.

• Step 5: Handle the authentication flow. If the second-factor verification is successful, grant access to the user. Otherwise, prompt the user to retry or provide an alternative authentication method.

The same steps can be performed if there are more than two authentication factors.

Storing MFA configuration

Different users can choose different authentication methods. For example, a user might choose to receive an OTP via email instead of their cell phone. It is advisable to remember their choice as it correlates with a good user experience. Also, consider providing an option for users to remember their device or session after completing the MFA successfully, as it reduces the frequency of MFA prompts for trusted devices or sessions.

Handling MFA challenges

• Error handling: Providing clear and informative error messages is a big challenge when integrating MFA into your application. These messages should explain the challenge and guide how to resolve it. For example, OTP codes received via email/SMS have a limited validity period, say 5 minutes or so. If a user attempts to use an expired OTP, you should provide a clear error message indicating that the code has expired. Prompt the user to request a new OTP code by following certain steps.

• Lost hardware tokens: What if someone loses their hardware token? It can be misused. You must provide instructions on deactivating or unregistering the lost hardware token from their account. Note that deactivation should also be authenticated. Users should verify their identity through secondary means to prevent unauthorized access.

• Compatibility Issues: You should not assume that no user will face compatibility issues when attempting MFA. Try maintaining an updated list of supported devices and software versions to assist users in selecting compatible options. This information can be included in the MFA setup process or the help documentation.

To learn more about integrating specific MFA providers, consider taking the following courses on Educative: Control Access to Your Applications Using Auth0 API in JavaScript and Authenticating Application Users with Okta in JavaScript.