With increasing security threats, using just the username and the password is not enough in modern apps. Multi-Factor Authentication (MFA) has become a standard security layer in enterprise and consumer applications. From the quality perspective, validating the security through MFA is of utmost importance. But the real challenge for QA engineers is to automate the login flows with MFA enabled.
In this article, we’ll explore Multi-Factor Authentication using Playwright and understand why MFA complicates test automation. We will also walk through practical strategies to handle MFA in automated test environments.
What is Multi-factor Authentication?
Multi-Factor Authentication (MFA) is a security mechanism that requires users to verify their identity using two or more authentication factors:
- Something you know – Password, PIN
- Something you have – OTP via SMS, email, authenticator app
- Something you are – Biometric (fingerprint, face recognition)
For example
- A user logs in with a password.
- The system sends a One-Time Password (OTP) to their mobile device.
- The user enters the OTP to complete authentication.
This layered verification reduces the risk of unauthorized access.
Why is MFA Challenging in Test Automation?
When automating login using Playwright, a simple login flow looks like this:
|
|
But when MFA is enabled
- An OTP is generated dynamically.
- The generated OTP has a time limit.
- It is generally delivered through an external system like SMS, an authenticator app, etc.
Automation scripts cannot manually read SMS messages or enter codes from physical devices. Hence comes the need to automate MFA- securely and responsibly.
How to Handle MFA using Playwright?
When automating login flows, MFA can block test execution since it requires a dynamic code that changes every time. Here are the common ways to handle it.
Disable MFA in Test Environments (Recommended Approach)
The most common and recommended practice is to disable MFA for automation test accounts in test environments. The reason why it is recommended is
- Automation should validate app functionality and not third-party OTP.
- MFA validation can be covered via integration testing separately.
To use this approach:
- We create dedicated test users.
- Configure the backend to bypass OTP for those users.
By doing so, we can ensure stable automation and faster execution. This is the simplest way to handle MFA in Playwright testing.
Using Time-Based One-Time Password (TOTP) in Playwright
Some applications use TOTP-based MFA (like authenticator apps).
TOTP codes are generated using a shared secret key. If the secret is available in test environments, we can generate OTP programmatically.
It means that instead of waiting for someone to read the OTP and enter it manually, the test script generates the OTP directly. This allows the MFA step to be fully automated.
For example, using the otplib package:
|
|
The sample code below shows OTP generation in Playwright:
|
|
As you can see from the above code, the OTP is getting generated from the server directly and is being passed through the script. There is no need to read the sms or email and manually enter the OTP.
It is important to note that production keys should not be exposed in the automation scripts.
Security Considerations while Automating MFA
While you are implementing MFA automation, you should keep in mind a few important points:
- Never use production secret keys in test repositories.
- Store secrets securely using environment variables.
- Periodically shuffle the test secret keys.
- Use specific test accounts to automate MFA.
- Ensure logs do not expose OTP values.
Common Mistakes while Automating MFA
- Hardcoding OTP values – Using fixed OTP values will make tests unreliable since OTPs change in regular intervals.
- Implementing fixed timeouts instead of proper waits – Relying on static delays can make tests flaky since OTP fields may load at different speeds.
- Testing OTP expiry using sleep function – Using sleep can slow down the tests and make them inefficient.
- Mixing security validations with functional validations – Mixing security and functional validations can make the tests complex and unstable.
- Ignoring retry limits in repeated login attempts – Not accounting for retry limits may result in account lockouts or security locks.
Final Thoughts
Multi-Factor Authentication is a strong way to strengthen application security, but it makes test automation complex. With Playwright, handling MFA can be easy using Time-Based One-Time Password (TOTP). By programmatically generating the OTP, you can make 100% automated tests for MFA scenarios.
Automating MFA should be done consciously, as improper implementation can further make the tests unstable and prone to security issues. The key principle should be to automate smartly and not automate something that should be isolated.
Using a structured authentication strategy, you can ensure high security standards of your Playwright test suites along with stability and scalability.