Web Google Auth - workaround for 403: disallowed_useragent exists?
Asked Answered
B

3

25

There are many StackOverflow posts about this issue, but none that offer a workaround for web apps to log into services via Google Web Auth in an embedded browser like Facebook/Facebook Messenger on iOS; but I discovered that Pinterest's web log in with Google button seems to be working, so I was wondering if someone has an idea how they got it to work.

Google disallowed logging into Google from webviews a few years ago, and Auth0 also made a blog post about workarounds, but it all seems to focus on native apps, not web apps that offer Google as a login option.

But my company's app is a web-app, and we'd like it if when someone shares a link to our site on Facebook Messenger/Facebook posts, users can log in with Google even if they don't pop out the native Safari browser. Based on the above documentation it would seem that that's not possible - but actually I discovered that Pinterest's "Sign in with Google" button does work! So it appears there's a way to get Google login working (not sure if they swung a special deal with Google, or if they're doing something we/Auth0 can be doing too, though).

Repro steps:

  1. Open Facebook Messenger in iOS (this should roughly work with Facebook too, but this demonstrates the issue)
  2. Send yourself a message with the URL https://community.auth0.com
  3. Click on the link to the Auth0 Community forum
  4. Click on Log In
  5. Click on Log in with Google
  6. See that you get a 403: disallowed_useragent error.

And to prove that there does seem a way for this to be done in the wild:

  1. Ensure your phone doesn't have Pinterest installed (or else your phone will open it in the native app).
  2. Open Facebook Messenger in iOS
  3. Send yourself a message with the URL https://pinterest.com
  4. Click on the Pinterest link
  5. Click on "Sign in with google"
  6. Somehow, it doesn't error when Pinterest does it!

Anyone have an idea what's going on here?

This issue has been cross-posted to Auth0's support community forum, since my team implements Google Auth through Auth0, but it seems generally relevant beyond Auth0.

EDIT: some more details from looking at the Google OAuth endpoint URLs my site vs Pinterest's:

Looking at the Google oauth URL my site uses vs Pinterest's, I see a few differences:

  1. Mine goes to https://accounts.google.com/o/oauth2/auth, theirs goes to https://accounts.google.com/o/oauth2/auth/identifier
  2. Theirs has a few extra query parameters mine doesn't:
["openid.realm", ""]
["ss_domain", "https://www.pinterest.com"]
["fetch_basic_profile", "true"]
["gsiwebsdk", "2"]
["flowName", "GeneralOAuthFlow"]
  1. Theirs has a different value for response_type of permission id_token, mine is code

not sure what would have an effect though.

EDIT: Same issue in this StackOverflow post from several months ago but no activity, and this one from 4 years ago but they claim there's no way - which seems to not be true since Pinterest is able to pull it off! Meanwhile both Spotify and StackOverflow also fail with this error. Maybe it's an inside deal...

Barbellate answered 18/12, 2020 at 8:27 Comment(9)
I'm trying to solve the same problem and also noticed Pinterest is the only web app with this working. We need to find a solution!Tantalizing
What did you end up finding out about this? How did you solve this problem?Road
Please tell me you found a solution. This is driving me crazyArnica
Nope never did.Barbellate
same issue here, any clue about this until now?Breastfeed
I cant believe this is such a problem... there is no need to tell you that i have the same issue here, but for the sake of it, did you find anything further?Wolfenbarger
Oh still nothing on this. Are we gonna tell the next generation of developers that we couldnt ever get around this @DobromirKirovUrgent
The tails of the forgotten Google Auth 403: disallowed_useragent... The story begins back in the past when we were on web2 and now 50 years later on web7 we still waiting for this to be resolved... @UrgentWolfenbarger
any solution here?? I'm having the same problem with Firebase auth...Corie
S
2

If you use a webview widget in android/iOS,you can simply modify the UserAgent to achieve the goal(It seems to be working when specify the browser UserAgent)

webview.getSettings().userAgentString="Mozilla/5.0 (Linux; Android 8.0; Pixel 2 Build/OPD3.170816.012) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Mobile Safari/537.36"
Susannasusannah answered 27/9, 2021 at 7:18 Comment(2)
well... this is solution for those "mobile apps", the poster said that they're web app. Which means they're not developing an mobile app, they're just website.Coriss
Damn... it worksImamate
L
1

TLDR: One way to resolve this is to perform the native authentication and then redirect the user back to the webview with id_token as a URL parameter.

Please note that this is not a quick and dirty solution. Changing the user agent violates Google policies and is not a long-term solution. It also seems to have stopped working.

Here is what the alternate flow looks like:

  1. User opens the app inside webview
  2. User clicks on the /sign_in path
  3. The app intercepts and will show a native view with the Sign in with Google button
  4. User finishes authentication and id_token will be generated as a result
  5. The native app redirects the user back to a webview endpoint and includes id_token as a parameter i.e. /sessions/create?id_token=123....
  6. The backend creates a user, sets a cookie, etc., and logs the user in

I am a Rails developer and I achieved this using Turbo. You don't need to be running Rails to use Turbo. There is a Turbo Android package that takes a heavy load for you and takes care of the majority of the points I mentioned above.

Some useful links:

Basecamp's both apps, Basecamp and Hey Email, are hybrid apps. I think 95% of the app is running on webviews and render HTML/CSS. Both the apps use Turbo/Hotwire and as far as I know, they have implemented a similar approach for Google Sign-In.

Lynettelynn answered 23/2, 2023 at 1:25 Comment(2)
This sounds promising! I can’t verify it now, and I’ve moved to another company and don’t have an immediate need to check it, but given the above note that Pinterests request uses an id_token response type, this sounds potentially along the lines of what they’re doing. If someone who still is experiencing this issue tries this out and it seems to work fine then happy to mark this one as the answer :)Barbellate
"Changing the user agent violates Google policies" - I believe the "Deceptive or unauthorized use..." section of the Google API Services User Data Policy is the policy mentioned above.Maloriemalory
P
0

for MAUI:

webView.UserAgent = "Mozilla/5.0 (Linux; Android 8.0; Pixel 2 Build/OPD3.170816.012) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Mobile Safari/537.36";

I belive you could set those user agent settings in your own custom web view.

Pronucleus answered 30/7, 2024 at 13:38 Comment(0)

© 2022 - 2025 — McMap. All rights reserved.