Why Google blocks OAuth in a WebView, and what to do instead
Google blocks sign-in inside embedded browsers. The reasons, the disallowed_useragent error and the right answer: Custom Tabs and PKCE, explained.
By Kra Ange Fabien Jephté (kra Axiom) · Published on 24 September 2026 · 2 min read
You add "Sign in with Google" to your PWA, everything works in Chrome, then you wrap it in an application: the button shows a 403: disallowed_useragent error. It is not a bug: it is a policy.
Why it is refused
A WebView is a browser controlled by the application that embeds it. That application can read input fields, inject JavaScript and intercept cookies. If a Google sign-in takes place inside that WebView, the application can therefore see the user's password. Google therefore forbids OAuth flows in embedded user agents and requires a "secure" browser, where the application cannot spy on the page.
The right answer
Open authentication in the system browser:
- Android: Chrome Custom Tabs, a browser tab presented inside the application.
- iOS:
ASWebAuthenticationSession.
Then come back to the application with the result:
- The application opens the authorization URL in the secure tab.
- The user signs in at Google, out of the application's reach.
- Google redirects to a return address: an application link (App Link / Universal Link) or a custom scheme.
- The application receives the code and exchanges it for a token.
Use PKCE
For an application, the client secret cannot stay confidential. The Authorization Code flow with PKCE protects the exchange: the application generates a one-time secret (code_verifier), sends its hash at the start (code_challenge) and proves it at the exchange. A stolen code is useless without that secret.
What is possible today with PWA2APP
In a generated application in REMOTE mode, only the origins you allow stay in the WebView: any other https link is opened outside the application, in a Custom Tab by default. A sign-in button that redirects to Google therefore leaves the WebView.
What does not exist yet: a dedicated Bridge method to start an authentication session and receive the return. It is not in the current Bridge version (see the roadmap). Meanwhile, handle the return with an application link to your domain.
Alternatives to consider
- E-mail sign-in with a magic link or a code.
- Passkeys, which avoid the password.
- A provider that allows embedded flows, knowing the risks.
Key takeaways
- Never sign a user in with Google inside a WebView.
- Use a Custom Tab and the Authorization Code flow with PKCE.
- Plan the return to the application through a link to your domain.
