Google OAuth for websites in embedded browsers

Question

Google no longer allowing embedded webviews as it is a disallowed_useragent for OAuth sign in. For most situations, this is completely fine and there is a workaround. However, I have run into a situation where this prevents websites from being able to use a web-server OAuth implementation.

The Issue:

Nginx PHP server running the Google PHP SDK, using their O-Auth implementation. This works fine on everything except embed browsers. Typically this is okay, however, if a user tries to sign up to our website in an app which uses an embedded browser, we get the disallowed_useragent error (See picture at bottom). This doesn't appear to be a problem in Android Facebook Messenger but can be replicated on the iPhone 7 Plus Facebook Messenger.

Current Research:

I tried to look for explicit workarounds. E.g. ways to force the link to open in the primary phone browser (e.g. Safari app) but all implementations point to app side fixes, which can't be done from a website.

Question:

How can I implement Google Oauth when some users may be using these embedded browsers, without making the user to take an extra manual action (e.g. Open in Safari/Chrome)?

Individuality

just take a look at this post, no other solutions #41830030 – Upkeep

Technically, you can set the user agent string for a webview to imitate a desktop browser. – Caisson

@Caisson the issue is for apps that you don't control, i.e. Facebook Messenger... – Individuality

Answer 1

This question is very opinion based but I will give you my opinion.

How should I implement Google Oauth when some users may be using these embedded browsers, without making the user to take an extra action?

You cant really. If someone is using an embedded browser in Facebook messenger (embedded browser) to open your auth link its not going to work. To my knowledge there is no way to force or over ride Facebook messenger or any other app that uses its own embedded browser. Again this is just my opinion but there are a lot of apps out which have started forcing their users to use these embedded browser's. One could question how secure they are and that it is better to use the real installed browser. Do you think this is why google has enabled this to begin with?

I would like to avoid going down the road of detecting the user-agent web-side and force the user to open the link in Safari.

I don't know that sounds like a pretty decent solution to me. It may feel a like over kill a little but if it works go with it.

Jim

Answer 2

There's another scenario that is causing issues. If you have a web app - not a native app with an embedded browser - the user can always choose to put the shortcut to the HomeScreen in iOS. But when they go to that HomeScreen shortcut to run the app, it will strip "Safari/6xx.x" from the user agent string. Now, Google sees this as an "Embedded Browser" and denies access to OAuth.

So - "No Web-App-Capable" for you!

If you turn off this meta tag:

<meta name="apple-mobile-web-app-capable" content="yes"/>

two things happen in iOS: The website now opens in the Safari browser window instead of the cleaner Web-App method. The website uses the complete Safari useragent which will allow OAuth to work.

The real shame here is that the decisions of Google (To deny non-standard browsers to access OAuth) and Apple (To remove the Safari version in the user agent for homescreen shortcuts) have backed us into the corner where any site that could look really nice in web-app mode can't utilize this OAuth from google.

I've been trying to find a way to spoof the user agent to add the safari version into it so that everything works in homescreen web-apps, but I don't think I can make it work. It seems that safari doesn't allow you to change the navigator.userAgent and on top of that, I'm not sure how it would handle new popup windows in WebApp mode.

Casey

I ran into exact that issue. Didn't find any solution to auth "Safari Embedded". – Redcoat