Gmail Android In-App Browser breaks email OTP authentication flows

Google Workspace Developers Q&A
1

On Android, when a user taps a link in Gmail, it opens in Gmail’s in-app browser. This creates a critical problem with email-based OTP authentication.

The flow:

  1. User receives a lifecycle email with a link to our website
  2. User taps link → opens in Gmail’s in-app browser
  3. User enters their email address, is prompted for an OTP code
  4. OTP is sent to the user’s email
  5. User needs to go back to Gmail to read the OTP
  6. Going back to Gmail closes the in-app browser — the page waiting for OTP input is lost
  7. User has no way to return to the OTP input page, opening the original links loses original context and resets OTP

The user is stuck. They can see their OTP code, but the page that needs it is gone.

This affects any web application that uses email-based OTP and is accessed via a link in Gmail on Android.

Is there any way to:

  1. Indicate to Gmail that a link should open in the device’s default browser rather than the IAB?
  2. Allow the IAB to persist when the user navigates back to Gmail, rather than closing?
  3. Reliably detect the Gmail IAB via user agent or other means?

This feels like a gap in the Chrome Custom Tab implementation within Gmail — the single-context nature of the IAB is fundamentally incompatible with any authentication flow that requires the user to check their email.

1 Like
3

Hello Mark

Stop using “email code OTP” for this entry path → use a magic link

Instead of: open link → type email → receive code → switch apps → page lost

Do: open link → type email → receive “Continue” link → tap link → verified

Why this works:

  • The user returns to your site by tapping a link in Gmail, which is exactly what Gmail supports well.

  • No need to copy a code from Gmail into a web page that may have been destroyed.

Implementation pattern

  1. User opens lifecycle link (contains your campaign context).

  2. User enters email.

  3. You send an email with a single-use signed verification link:

  5. Clicking it verifies and redirects to the correct place.

Security notes (do these):

  • token one-time use + short expiry (e.g., 10–15 min)

  • bind token to email + original campaign/session id

  • rate limit requests / resend

This is the most compatible approach with Gmail IAB constraints.

4

Thanks Abhishek, magic links are a good option but not supported by auth0 universal login unfortunately. Are there any options to just tell gmail to hand off to an actual browser? This feels like an undesired effect for users where it opens in IAB.

5

Hello Mark

Universal Login’s preference for OTP is a known issue . Since you want to keep the current Auth0 setup, the best way to ‘force’ a hand-off to the browser is to use an Android Intent redirect but it must follow Compliances of Privacy Laws (GDPR/CCPA).

By breaking out of the In-App Browser, you’re moving the user from a potentially ‘untrusted’ webview into a ‘trusted’ system browser. Just make sure the redirect token is cryptographically signed and expires quickly , to stay compliant with standard security audits like SOC2 or GDPR.
Thanks

6

How would we do that? Note that the user will be clicking a link in Gmail, and the desired destination is their browser.

We also don’t know ahead of time if the user is on android, iOS or desktop so whatever we do must work cross-platform.

1 Like