Google sign-in in a WebView fails because Google blocks it on purpose. Since September 30, 2021, Google’s OAuth server refuses sign-in requests from embedded browsers such as Android WebView and shows Error 403: disallowed_useragent. Your app isn’t broken; you need to move the Google login into the real browser or a native sign-in.
Why Google blocks sign-in inside a WebView
Google blocks sign-in inside a WebView because the app that hosts the WebView can see and change everything on the page, including the login form. Google’s announcement says embedded webviews let “a nefarious developer” intercept and alter traffic between Google and users. They can also remove the browser parts that users rely on to trust a page, like the address bar.
On Android, the same post says webviews “implementing or extending Android WebView do not comply” with Google’s secure browser policy. That covers every app that wraps a website in a WebView, whether it was written by hand or made with a builder.
Google isn’t alone. RFC 8252, the OAuth standard for native apps, says native apps “MUST NOT use embedded user-agents” for authorization requests. The reason given is that the host app can access the user’s full authentication credential.
What the disallowed_useragent error looks like
The disallowed_useragent error is the page Google shows when a sign-in request comes from a blocked embedded browser. Users tap “Continue with Google” and, instead of the account picker, get a Google page with Error 403: disallowed_useragent.
Developers on the Auth0 community hit the 403 whenever Google login opened inside an embedded browser. The confusing part: the same site works in Chrome on the same phone.
Why changing the user agent is a bad fix
Changing the WebView’s user agent hides the symptom without fixing the policy problem. A Stack Overflow thread shows developers trying exactly that.
Google’s OAuth 2.0 policies say a developer “must not direct a Google OAuth 2.0 authorization request to an embedded user-agent.” The policy also says every browsing environment must let the user verify the connection to Google’s OAuth server. A WebView with a fake user agent still can’t do that. Don’t ship a disguise. It can stop working the day Google tightens its checks, and your users get locked out.
How to fix Google sign-in in a WebView app
The fix for Google sign-in in a WebView app is to send the login step out of the WebView. Which route fits depends on how much of the app and site you control.
| Your setup | Best fix | What changes |
|---|---|---|
| You write the Android code | Native Sign in with Google | Login uses Google’s Android sign-in, not a web page |
| You write the Android code and use OAuth on the site | Open the login in Custom Tabs | Login runs in the user’s browser |
| No-code WebView builder, you control the site | Add email, password or magic-link login | Users who can’t use Google still get in |
| No-code builder, no site changes | Open sign-in links in the system browser | Login completes in Chrome, outside the app |
Native Sign in with Google
Native sign-in replaces the web login with Google’s own Android flow. Android’s Credential Manager guide covers Sign in with Google for sign-up and sign-in. Your site’s backend then needs to accept the result from the app, so this is a real code change on both sides.
Chrome Custom Tabs
Custom Tabs open the login inside the user’s real browser while still looking like part of your app. Chrome’s Custom Tabs docs describe them as a browser experience powered by the user’s preferred browser. Google’s announcement names Android Custom Tabs as an accepted alternative.
For OAuth, the AppAuth-Android library follows RFC 8252 and uses Custom Tabs. Its README says WebView is explicitly not supported, for usability and security reasons.
The catch: the session lands in the browser, not your WebView
A Custom Tabs login signs the user into the browser, and your WebView doesn’t automatically share that session. Chrome’s docs list a “shared cookie jar” with the browser as a feature of Custom Tabs, which is why sites the user already uses stay signed in there.
Your app still has to get the result back. The usual pattern is a redirect to an address the app handles, which then loads a page in the WebView that starts the user’s session. Skip that step and users sign in, return to the app and find themselves still logged out.
What this means for no-code WebView apps
A no-code WebView app can’t run Google sign-in inside its WebView, no matter which builder made it. The block sits on Google’s servers, not in the app.
WebToAPK Free builds WebView apps, and it warns that sign-in, downloads, permissions and external links can behave differently than in Chrome. It also tells you to test authentication on real devices before you publish. If your site’s only login is “Continue with Google”, a plain WebView wrapper won’t get users past it. Add a second login method on the site first.
If you’re still deciding between approaches, compare a PWA and a WebView app or read about Trusted Web Activities, which show your site in the browser instead of a WebView. Logins aren’t the only thing that changes in a wrapper: file downloads break in WebView for similar reasons. Before you submit, check whether Google Play rejects WebView apps.
FAQ
What does Error 403: disallowed_useragent mean?
It means Google refused the sign-in because the request came from an embedded browser such as Android WebView. Google’s policy blocks OAuth requests from those environments. The fix is to sign in through the real browser or a native Google sign-in.
Can I change the WebView user agent to make Google sign-in work?
People try it, but it goes against Google’s secure browser policy, which forbids sending OAuth requests to an embedded user-agent. Even if a disguise works today, it can break without warning.
Do Chrome Custom Tabs work with Google sign-in?
Yes. Custom Tabs run inside the user’s real browser, which is what Google’s policy asks for. Google’s own announcement names Android Custom Tabs as an alternative to embedded webviews.
Does Facebook or Apple sign-in work in a WebView?
This post only covers Google’s policy. The OAuth standard for native apps, RFC 8252, says no provider’s login should run in an embedded user-agent, so test every provider before you publish.
Can a no-code WebView app use Google sign-in?
Not inside the WebView itself. Offer an email or password login as well, or use a builder that opens sign-in in the system browser and returns the user to the app.
Sources
- Upcoming security changes to Google’s OAuth 2.0 authorization endpoint in embedded webviews, Google Developers Blog
- OAuth 2.0 Policies, Google for Developers
- RFC 8252: OAuth 2.0 for Native Apps
- Custom Tabs, Chrome for Developers
- Sign in with Google with Credential Manager, Android Developers
- AppAuth-Android, OpenID Foundation
- Auth0 Community: disallowed_useragent 403 error with Google sign in
- Stack Overflow archive: workaround for 403 disallowed_useragent