Playwright Google OAuth
You set up playwright google oauth by exchanging refresh tokens or saving browser session state. This lets your automated tests log in without clicking through Google login screens. Many teams create a shared test user and give it broad admin permissions. When a test account has wide roles, any leaked session token creates big risks. How playwright google oauth works in browser tests Google blocks automated browsers from typing passwords into its standard sign-in forms. Bot checks and two-fac
OAuth 2.0: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up playwright google oauth by exchanging refresh tokens or saving browser session state. This lets your automated tests log in without clicking through Google login screens. Many teams create a shared test user and give it broad admin permissions. When a test account has wide roles, any leaked session token creates big risks.
How playwright google oauth works in browser tests
Google blocks automated browsers from typing passwords into its standard sign-in forms. Bot checks and two-factor prompts will stop a normal test run right away. Because of this, teams skip the visual login screen during test runs.
The first way uses a saved browser state file from a one-time login. A developer logs in once and saves the cookies and local storage data. Before each new test run, the test runner loads this saved state file. The app sees a valid session and lets the test user in fast.
The second way uses the Google token endpoint before the browser opens. Your test script sends a client ID, a client secret, and a refresh token. Google checks these keys and sends back a fresh access token. The test script then puts this token into the browser storage or headers. This API flow runs fast and avoids flaky UI steps in your pipeline.
What native test login solves and what it misses
Using API tokens or saved state files solves the problem of flaky tests. Your pipeline runs on a schedule without failing on Google bot checks. It also speeds up the test suite since tests skip the login page.
Still, this native setup leaves a major security gap in your test systems. The setup only decides who logs in at the start of a run. It does not check what individual requests, commands, or queries do in flight. Teams often store long-lived refresh tokens or state files in shared CI secrets.
OAuth 2.0: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
To make tests pass, teams give these test accounts broad database and API roles. Anyone who can read the CI logs or secret store can take those keys. If a test script or developer misuses that token, native login cannot stop destructive commands. It also fails to rewrite sensitive fields like emails, phone numbers, or card numbers in test outputs.
Securing test accounts and CI session state
To lower risk, teams must limit what the Google test account can do. Create a dedicated test user in a separate Google workspace domain if possible. Give that user the smallest role needed to run the specific test suite. Do not reuse the same broad admin account for every single test run.
Treat saved browser state files just like raw passwords or API keys. Never commit state files to your code repo, even in private branches. Set up your CI runner to delete the state file after the job ends. Rotate the refresh tokens on a set schedule and watch your logs for odd runs. Even with these steps, account rules alone cannot inspect live actions inside a session.
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
Why does Google block my automated browser during login?
Google watches for automated browser flags to stop spam and credential stuffing attacks. When it sees a test runner, it triggers captchas or blocks the sign-in attempt. You should use API tokens or saved session states instead of typing passwords.
How long does a saved browser session state last?
Session cookies expire based on the rules set by your app and Google. Most teams generate a fresh state file at the start of each CI run. Using a refresh token via an API call helps you get fresh cookies every time.
Is it safe to store refresh tokens in CI variables?
Storing refresh tokens in masked CI variables is common, but it carries risk. Any person or script with build access can read and export that token. Always pair CI secrets with strict role limits and action checks on your backend systems.