Skip to main content

Google Authentication with MFA – Why Am I Asked for a Phone Verification?

Ines avatar
Written by Ines
Updated over a week ago

Prerequisites

Before reviewing the available workarounds, keep in mind:

  • This issue occurs when authenticating a Google account protected by MFA (SMS, OTP, prompts).

  • It affects both Google Workspace and personal Google accounts.

  • This happens regardless of the location you are executing from

What Is This Issue About?

Some users experience a phone number verification request when trying to sign in through Thunders.

This challenge appears during Google’s authentication flow because the login attempt originates from a new IP address, not because of a missing or misconfigured geographic region.

In short:

Google detects a new IP → flags the login → enforces phone/MFA verification.

Even if you add “Canada” or another region in Thunders’ test settings, Google will still require additional verification.

Why Does It Happen?

Google continuously evaluates login attempts using:

  • Device fingerprint

  • Location history

  • Account risk profile

  • MFA settings

Since Thunders executes from a different IP than your usual device, Google interprets the login as “untrusted” and triggers extra verification (SMS, prompt, etc.).

This is expected behavior from Google and cannot be bypassed through standard settings.

Available Workarounds

Below are practical solutions adopted by teams who must run tests involving Google authentication.

They are listed from most stable to least recommended.

Option 1 — Google Workspace Test Accounts (Recommended)

How it works

  • Create dedicated test accounts inside a separate Google Workspace domain.

  • Disable MFA and strict security policies only for these test accounts.

  • Use these accounts exclusively for automation and testing.

Benefits

  • Stable

  • No OTP, no CAPTCHA

  • No need to manage cookies or tokens

  • Fully supported by Google’s best practices

Prerequisites

  • Admin access to a Workspace domain (often paid)

This is the cleanest and most reliable long-term approach.

Option 2 — OAuth Test Users / Service Accounts

How it works

  • Use Google Service Accounts for backend/API flows.

  • Create a /login-for-test page in your application that:

    1. Authenticates server-to-server with a Google test account

    1. Redirects the user already logged in

Benefits

  • Avoids CAPTCHAs and OTP entirely

  • Strong security model

  • Works reliably for backend-driven flows

Limitations

  • Requires development on your application

  • Not suitable for all frontend login flows

Perfect for applications with backend-based identity flows.

Option 3 — Pre-Authenticated Session (Cookie Injection)

How it works

  1. Log in manually once using MFA.

  2. Export cookies/storage using storageState().

  3. Reuse this authenticated session in your tests.

⚠️ Limitation

  • Session expires → you must re-authenticate manually.

  • Not scalable for large teams.

  • Cookie injection is on the Thunders roadmap for native support.

Useful as a temporary workaround, not ideal long-term.

Option 4 — OTP Automation (Coming soon)

Thunders will soon offer an ability to automate OTP, using Thunders email accounts and Phone numbers:

  • Email-based MFA using Thunders virtual server

  • Virtual SMS services

However:

  • These introduce some security risks if you use real accounts

  • They could Google’s security expectations

  • They are more fragile (SMS can sometimes not arrive to destination, emails as well)

Because of this, we do not recommend automating MFA for real Google accounts.

Need Help Implementing Your Solution?

We’re happy to guide you through whichever workaround fits your product and constraints.

You can reach us anytime at [email protected] - our team will help you set everything up smoothly.

Did this answer your question?