Both Android and IOS devices have a mechanism to detect captive portal on Guest Wifi networks. Whenever a captive portal is detected, these devices start an embedded browser in order to show up the captive portal.
My captive portal allows my guest wifi to use their Google auth credentials in order to allow access to my wifi.
The portal triggers an OAuth 2.0 with Google service and get back the user profile.
All was working fine, unfortunately, Google decided to stop supporting OAuth 2.0 in Embedded browser on April 22nd.
https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
As far as I know, there is no way to force IOS or Android devices to start a real browser during the captive portal detection process.
Since this embedded browser can't be controlled, what option do I have to allow my guests to use their Google credentials? If there is no alternative option, I will have to migrate to Facebook auth modules which doesn't have this restriction as of today.
Thanks, William
I'm not cool enough to comment apparently, so I'll just reply that despite @nvagr stating that google will not be broken in the CNA, it is. You cannot log in using Google oAuth on an iOS device. You'll get a 403: disallowed_useragent because it uses the CNA.
Update 1/23/2019: If you do have a client that need to do a sign-in inside the captive portal, please send the client id, description of your portal and users and other details to oauth-feedback@google.com
Update (4/7/2017): For now we have decided that we'll not break the Google sign-ins within captive portals. If you do have a client that is broken, send me the client id.
Thanks William for this note regarding Captive portal. We (Google Identity team) need to do some investigation to decide how to best support your use case. I'll reply back on this thread. Stay tuned.
来源：https://stackoverflow.com/questions/41829530/google-oauth-2-0-and-captive-portal-with-embedded-browser