How to Automate Otp in Playwright
To understand how to automate otp in playwright, generate codes from a shared secret key. You can also fetch one-time codes from a test email or message inbox API. Engineering teams often set up test accounts to run browser login tests on a schedule. Still, broad permissions on these test roles create security risks across your staging systems. How to automate otp in playwright with secret keys and APIs Playwright runs fast browser checks by acting like a real user on a page. When a login for
Right to Erasure Implementation + Just-in-Time Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To understand how to automate otp in playwright, generate codes from a shared secret key. You can also fetch one-time codes from a test email or message inbox API. Engineering teams often set up test accounts to run browser login tests on a schedule. Still, broad permissions on these test roles create security risks across your staging systems.
How to automate otp in playwright with secret keys and APIs
Playwright runs fast browser checks by acting like a real user on a page. When a login form asks for a two-factor code, the test script must pause. The script then gets the valid six-digit code from a trusted source. Teams use two main methods to get this code during a test run.
The first method uses time-based one-time passwords built from a shared secret key. When you set up a test user, the identity system shows a setup key. You save this secret key in your secure test store. During the login run, a helper library reads the secret key and the current time. It computes the right code on the fly, and Playwright types it into the form.
The second method works when the app sends codes by email or text message. Your test script triggers the login prompt and waits for the message to arrive. It then calls the API of a test inbox service to read the latest message. A text matcher pulls the six digits from the message body. Playwright fills the input box and submits the page to finish the login.
Once the login finishes, Playwright can save the browser state to a local file. Later tests load those saved cookies and tokens to skip the login step. This keeps your test suite fast and cuts down on external API calls.
What native OTP automation solves and what it misses
Automating the one-time password flow lets your team test real security paths before release. You do not have to turn off two-factor checks in your staging apps. Your tests verify that the login screen works from start to finish.
Still, this native setup creates a new problem with secret keys and long-lived sessions. The test runner needs access to raw secret keys, inbox API keys, and passwords. Anyone who can read the test runner logs or files can take those keys. A leaked secret key lets an attacker make valid two-factor codes at any time.
Right to Erasure Implementation + Just-in-Time Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Also, login checks only control who gets into the app or database at the start. Once a test user or engineer logs in, the system trusts the whole session. Native login rules cannot inspect what single queries or commands run during that active session. If a test script has admin rights, a bad command can wipe shared staging tables. In the same way, an exposed test account could pull real emails or phone numbers.
Managing secrets and test sessions safely
To lower this risk, teams must limit what test accounts can do after login. Start by giving each test user the smallest role needed for the job. Never run browser checks with a master admin role or production user key.
Keep your time-based secret keys out of source control and plain text files. Load them into memory only when the login test needs to make a code. Rotate your test user keys and inbox tokens on a regular schedule. Clear out saved browser state files as soon as the test suite finishes its run.
When tests run against databases or internal tools, watch the commands that happen in flight. Masking rules can rewrite sensitive fields like card numbers or national IDs in query results. This keeps test logs clean and stops real user data from leaking into build artifacts.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Should we turn off OTP in staging to make Playwright tests easier?
No, turning off two-factor checks in staging hides bugs in your real login flow. Keep it on for at least one smoke test using a shared secret key. Other tests can reuse the saved browser session state to run fast.
Which OTP method is more reliable for automated browser tests?
Time-based codes from a shared secret key are much faster and more stable. They run locally in memory and do not wait on slow email or text delivery.
How do we stop test accounts from leaking sensitive data in logs?
Give test roles narrow permissions and never let them query raw production tables. Use data masking in your data layer to rewrite emails and phone numbers in results.