Automate Despite Multi-Factor Authentication

Introduction

Multi-factor authentication (MFA), or two-factor authentication (2FA), refers to the security action needed by users to supply more than one type of authentication to access a system.

MFA is prevalent nowadays with many websites and applications enhancing their security and privacy protocols. One automation process can involve multiple websites and applications that require an MFA. If an MFA isn't considered in the architectural design stage, development time may end up being much longer than the original estimates. 

Multi-factor authentication in automation

MFA is designed in part to prevent log in without the presence of a human. That said, don’t let it stop you from automating tedious, manual tasks. There are multiple ways to handle MFA in the context of automation. 

First, some websites/apps allow the second way of authentication be done through email, meaning the website/app will send the user an email with a code to Enter into the site/app. In these scenarios, you can add a workflow to your automation to check email inbox for the email, then use a regular expression (Regex) to parse out the authentication code from the email body. 

If the app requires authentication via a mobile app, most MFA systems offer a way to issue a token that can be used in place of the actual authentication mechanism (most of the time, the "secret key"). UiPath has a custom activity that specifically uses the secret key to bypass MFA. Custom activity can be downloaded free of charge from UiPath Marketplace.

Most people have been able to use one of the approaches above — for the second way, as long as the website or application uses a secret key as part of their MFA mechanism. There have been times when an application doesn't use or provide this secret key. In that case, the above custom activity alone cannot resolve MFA. 

The following are some alternatives to using the above custom activity: 

1. Twilio powers a web app named Authy (https://authy.com/). We’ve seen companies use this to bypass MFA. In instances where a human user is required to authenticate through their mobile phone, Authy provides a web interface in place of the mobile phone interface, allowing a robot to interact with a web UI instead. 

2. If the MFA uses a Google token, a Google Authenticator Chrome extension can be downloaded to authenticate instead of requiring a user to authenticate through the Google Authenticator mobile app. This is similar to #1 above.

3. Have your client check with the support team of the third-party app/site to see if MFA can be disabled. Oftentimes it can be easily disabled. 

4. Explore options to bypass MFA via an API call (if API is available). Please find the detailed approach in this white paper.

5. Develop the robot as an attended robot instead of unattended. That way, a human user can take care of the log in before handing it off to the attended robot. (This one is more of a last resort.) 

6. Have a human hand-off where the human user can log in on the robot server before the robot carries out the process. Additionally, if the session can remain logged in for a long time, then the human user just needs to log in periodically, and then the robot can proceed using the opened session. Or, a robot can send humans a notification email whenever human assistance is needed for the log in. This way the robot can remain unattended. 

Conclusion 

Don’t let MFA stop you from automating, and don’t jump to attended automation right away just because the application you are automating requires MFA. There are multiple ways to handle MFA from the RPA perspective. To read a more in-depth explanation on the topic, here's additional guidance on MFA from UiPath.