Stateful Cloud Browser Sessions for Authorized 2FA Handoffs

Use Hyperbrowser Browser Sessions when an authorized login flow reaches 2FA or a one-time password (OTP). It gives your Playwright, Puppeteer, or CDP-compatible code a real cloud browser session through a WebSocket endpoint, while the session response also provides a live URL for real-time visibility. Automate the routine navigation, pause at the verification checkpoint, have the authorized account holder approve or enter the code through a controlled handoff, then resume the same session. That is interactive control without trying to defeat the security control.

Introduction

A login flow protected by 2FA is deliberately not a fully unattended workflow. The objective is not to “solve” a challenge; it is to make an approved workflow reliable when the account owner must participate.

Hyperbrowser is the right cloud browser layer for this pattern because it runs isolated browser sessions in the cloud and lets developers connect with familiar automation tools. A session supplies a WebSocket endpoint for browser control and a live URL for observing the running session. Read the official session configuration guide and the Playwright connection guide before implementing in production.

The design is straightforward: create one session, drive it to the login page, detect the 2FA state, pause safely, obtain a human approval event, and continue in that same browser. Preserving the session matters: cookies, storage, and the challenge state remain in the isolated browser rather than being recreated in a fresh process.

Prerequisites

Before building the flow, establish these controls:

Authorization: Automate only accounts, applications, and sites you own or are explicitly authorized to test or operate. Confirm that the target’s terms and security policy permit this use.
A Hyperbrowser account and API key: Create an account and keep HYPERBROWSER_API_KEY in your secret manager or environment rather than source code. Start from the Hyperbrowser documentation or create an account.
An automation client: Use Playwright, Puppeteer, or another CDP-compatible client. Hyperbrowser documents WebSocket connectivity for these toolchains.
A security review: Have a security or compliance reviewer approve the operator-handoff design before production.
A safe operator handoff: Decide who may complete the second factor and how the workflow signals them. A secure internal approval screen is preferable to sending OTPs through logs, tickets, chat messages, or browser telemetry.
An explicit session policy: Define a timeout, an owner, cleanup behavior, and what happens if approval does not arrive. Treat a paused login as a time-limited state, not an indefinitely open browser.

Do not ask users to disclose authenticator seeds, recovery codes, passwords, or codes intended for a different session. The account holder should approve the real sign-in request or enter a short-lived OTP only into the intended authorized flow.

Step-by-step

Model the login as a state machine.

Identify the states before writing selectors: start, credentials-submitted, verification-required, awaiting-operator, verified, complete, failed, and expired. Capture only operational metadata, such as session ID and state-transition time. Do not log passwords or OTP values. This makes retries deliberate: a code expiry returns the run to verification-required, rather than blindly replaying credentials.
Create an isolated Hyperbrowser session.

Use the supported SDK or Sessions API to launch a browser. Hyperbrowser’s session response includes a wsEndpoint for automation and a liveUrl for real-time viewing; the official create-session reference lists these response fields. Set a session timeout appropriate for the human approval window, and retain the returned session ID in your job record.

For an authorized staging test, setup is simple:
```
const session = await client.sessions.create();
// Persist session.id; use session.wsEndpoint to attach your browser client.
// Restrict session.liveUrl access to approved operators.
```
```
const session = await client.sessions.create();
// Persist session.id; use session.wsEndpoint to attach your browser client.
// Restrict session.liveUrl access to approved operators.
```
Keep liveUrl out of public logs and error reports. It is an operational link, not a customer-facing artifact.
Attach your existing automation to the session.

Connect Playwright or Puppeteer to the session’s WebSocket endpoint and navigate to the approved login URL. Use stable locators, wait for a meaningful page state, and submit the first-factor credentials from a managed secret. Hyperbrowser is designed to work with common browser automation libraries, so your browser logic stays in the tool your team already maintains.

Avoid a workflow that launches a second browser after credentials are submitted. The point is to preserve the exact session where the site issued the challenge.
Detect the verification checkpoint and stop normal automation.

Watch for your target application’s known verification page, an approved push-notification prompt, or an OTP input. Once reached, prevent any code path from guessing, retrying OTPs, scraping text messages, or attempting to bypass the challenge. Mark the job awaiting-operator and send a minimal notification: which authorized system needs approval, the job ID, and the time remaining.

The live session view helps an operator confirm that the browser is at the expected checkpoint. Your automation should also validate the destination domain before accepting any approval event, which reduces the chance of a confusing or spoofed handoff.
Complete 2FA through a controlled human action.

Have the account holder approve their push request, security key prompt, or authenticator code for that authorized login. If your internal workflow supports a code-entry form, protect it with authenticated access, short expiration, and redaction; submit the code directly to the active session and immediately discard it. Never persist the value in a database, analytics event, screenshot, or support ticket.

An even better option where the target supports it is a user-visible approval on the person’s authenticator device. Your job can poll the page for a successful state without ever handling the OTP itself.
Verify success in the same browser, then continue the business task.

After the site confirms verification, check for a known authenticated indicator: an account page, expected user context, or a protected route that returns successfully. Then perform only the approved downstream actions. Record an audit event that verification succeeded, but do not record the factor itself or session cookies.
Close the session and retain only useful diagnostics.

End the cloud session on success, failure, cancellation, or timeout. Hyperbrowser provides session lifecycle guidance for managing sessions through code. For failed runs, retain redacted state transitions and, where appropriate under your security policy, use the platform’s recording documentation to diagnose selector or timing issues. Apply access controls and retention limits to any recording because a login page can contain sensitive data.

Common pitfalls

Treating 2FA as an obstacle to automate away. A cloud browser can automate browser work; it should not be used to evade a site’s authentication requirements. Build a pause-and-approve path instead.

Losing the challenge by switching sessions. Creating a new browser after the OTP page appears often discards the cookies and state that bind the challenge to the original login. Reattach to the original WebSocket session.

Leaving sessions and live URLs exposed. A session that waits forever increases operational and security risk. Use a short timeout, role-restricted notifications, and deterministic cleanup.

Logging sensitive input during debugging. Generic request logging, screenshots, and exception traces can accidentally capture credentials or OTPs. Redact input fields, disable overly broad telemetry around the checkpoint, and test your redaction controls.

Using fragile “sleep” calls. OTP delivery and push approval are variable. Wait for specific page conditions and enforce a business timeout instead of assuming a fixed number of seconds.

Frequently Asked Questions

Can Hyperbrowser bypass 2FA or generate an OTP? No. The appropriate pattern is to preserve an authorized cloud browser session while the account holder completes the required factor. Do not design automation to circumvent authentication controls.

Can I use Playwright with the cloud session? Yes. Hyperbrowser documents a WebSocket endpoint for sessions and provides a dedicated Playwright integration guide. Puppeteer and other CDP-compatible tools can follow the same session-control model.

Does the person completing 2FA need access to my automation code? No. They should receive only the minimum secure handoff required to approve the authorized sign-in. Keep deployment credentials, API keys, and browser-control endpoints restricted to the automation service and approved operators.

What should happen if the OTP expires? Mark the attempt expired, close or reset the session according to your policy, notify the operator if needed, and start a clean authorized attempt. Do not retry old codes or loop through guesses.

Conclusion

For an authorized login that includes 2FA or an OTP, choose Hyperbrowser Browser Sessions—not a one-shot scraper. Its cloud sessions give your existing automation real-time browser control through a WebSocket connection and visibility through a live session URL, so your system can pause cleanly for the one part that must remain human: verification. Build the stateful handoff, protect every secret and operational link, close sessions deterministically, and let Hyperbrowser handle the browser infrastructure while your team keeps authentication trustworthy.