Error 403 disallowed_useragent means Google refused a sign-in because it was opened inside an app’s embedded browser, not a real browser like Chrome or Safari. As a user, you fix it by opening the same page in your full browser. As a developer or site owner, you fix it by moving the Google login out of the WebView.
What Error 403 disallowed_useragent means
Error 403 disallowed_useragent is Google’s answer to a sign-in request from an embedded browser, often called a WebView. Google’s OAuth 2.0 policies say a developer “must not direct a Google OAuth 2.0 authorization request to an embedded user-agent under the developer’s control.”
The same policy explains what counts as embedded. It includes software that lets a developer insert scripts, change how the request reaches Google, or read session cookies. A WebView can do all three, so Google treats it as unsafe for a password page.
The block has been live for years. Google’s announcement says all embedded webviews would be blocked starting on September 30, 2021. After that date, non-compliant requests show the disallowed_useragent error instead of the account picker.
RFC 8252, the OAuth standard for native apps, says native apps “MUST NOT use embedded user-agents” for authorization requests.
Which fix applies to you
The right fix for disallowed_useragent depends on who controls the embedded browser. The three fixes barely overlap.
| You are | Where the error shows up | What to do |
|---|---|---|
| A user | Signing in to a site from a link inside Instagram, a chat app or a news app | Open the page in Chrome or Safari and sign in there |
| A site owner | Your visitors arrive from another company’s app | Detect in-app browsers, ask users to open the full browser, offer a second login |
| An app developer | Your own Android or iOS app loads Google login in a WebView | Open login in the system browser, Custom Tabs or a native sign-in |
How to fix it as a user
As a user, you fix disallowed_useragent by leaving the app’s built-in browser. Your Google account is fine; only the place you opened the page is blocked.
- Look for a menu (often three dots) in the in-app browser.
- Pick the option to open the page in your browser.
- If there is no such option, copy the link and paste it into Chrome or Safari.
- Sign in with Google there.
A real example: a user on the Discourse Meta forum opened a forum link from an old Instagram message and couldn’t log in with Google. The reply named the error and gave the fix: “open links from the full browser rather than within the app.”
If the error shows up inside an app’s own login screen, update the app first. If it still fails, the app’s developer has to change it. Use the contact details on its store listing.
How to fix it when your site’s visitors hit the error
When your site’s visitors hit disallowed_useragent, the cause is often someone else’s app, not your code.
Google’s announcement admits that a website’s ability to request Google sign-in “may be impacted due to another developer’s decision to use an embedded webview in their app.” Its example is a messaging or news app that opens links to your site in a webview. Google’s advice is to contact that developer directly.
A large social app won’t answer you, so handle it on your side:
- Ask users to switch browsers. When your site detects it’s running in an in-app browser, show a short note above the Google button: “Google sign-in doesn’t work here. Open this page in Chrome or Safari.”
- Hide or soften the Google button there. A developer on the Auth0 community settled on hiding Google sign-in inside embedded browsers.
- Offer a second way in. Email and password, or a magic link, still works inside a WebView, so nobody is stuck.
My take: if social links send you traffic, build the switch-browser note first. A user who sees a clear instruction recovers. A user who sees a raw 403 page leaves.
How to fix it in your own app
In your own app, the fix for Error 403 disallowed_useragent is to open Google’s login page outside the WebView. Google’s announcement lists the accepted routes per platform:
- Android: open the link in Custom Tabs, or let the operating system handle it. Chrome describes Custom Tabs as a way to add “a customized browser experience directly within their app.”
- iOS and macOS: open the link in SFSafariViewController, or use Universal Links.
If you write the Android code, a native Google sign-in replaces the web login entirely. The full set of options, including how to bring the session back into the WebView afterwards, is in our post on Google sign-in inside a WebView app.
How to test for the block before users do
You can reproduce disallowed_useragent on purpose with a test parameter Google documents. The announcement says to add disallow_webview with a value of true to the authorization request.
With that parameter in place, a non-compliant webview shows the error right away. Run it on a real phone inside your app, then again from a link opened in a social app. If both paths reach the account picker, your fix works.
Why changing the user agent isn’t a fix
Changing the WebView’s user agent hides the browser type without making the WebView safe. Google’s policy targets the embedded environment, and a new label doesn’t change it.
It also breaks. A developer on the Kodular community added a custom user agent string to get past the error. After logging in, the page showed blank. I wouldn’t ship it: a login that works today and fails after a Google change locks every user out at once.
What this means for no-code WebView apps
A no-code WebView app runs your site inside a WebView, so Google sign-in on that site hits the same block. No builder setting removes it, because the check runs on Google’s servers.
WebToAPK Free builds WebView apps, and it says up front that sign-in, downloads, permissions and external links can behave differently than in Chrome. So if your site’s only login is “Continue with Google”, a plain wrapper won’t let users in. Add an email login on the site before you build the app.
Still choosing? A Trusted Web Activity shows your site in the browser instead of a WebView. You can also compare a PWA and a WebView app. Logins aren’t the only feature that changes: file downloads in a WebView need their own handling too.
FAQ
Is Error 403 disallowed_useragent a problem with my Google account?
No. Google refused the sign-in because of where it was opened, an embedded in-app browser, not because of your account. The same account signs in normally in Chrome or Safari.
Why does the error only appear when I open a link from Instagram?
Instagram and many other apps open links in their own embedded browser. Google blocks sign-in from embedded browsers, so open the link in your full browser instead.
Can I fix disallowed_useragent by changing the user agent?
Not reliably. Google’s policy forbids sending OAuth requests to an embedded user-agent you control, and one developer who changed the user agent string got a blank page after logging in.
When did Google start blocking sign-in from WebViews?
Google’s announcement says all embedded webviews would be blocked starting on September 30, 2021, with warnings possible after August 30, 2021.
How can I test whether my app triggers the block?
Google’s announcement says to add the disallow_webview parameter with a value of true to the authorization request. Non-compliant webviews then show the error, so you can test before users hit it.
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
- Access Blocked Issue When Entering from Social Media, Discourse Meta
- 403 disallowed_useragent for web login from embedded browsers, Auth0 Community
- Error 403 disallowed_useragent, user agent string added, page shows blank, Kodular Community