osdiab
osdiab

Reputation: 2160

Web Google Auth - workaround for 403: disallowed_useragent exists?

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...

Upvotes: 25

Views: 18663

Answers (3)

Ricardo Veloz
Ricardo Veloz

Reputation: 29

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.

Upvotes: 0

Kartikey Tanna
Kartikey Tanna

Reputation: 1459

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.

Upvotes: 0

blink
blink

Reputation: 59

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"

Upvotes: 1

Related Questions