PKCE Google Login error disallowed_useragent

Get Help
, , , ,
1

Hi,

After the excellent advice from @nicolas_sabena I implemented the Native flow in our iOS app when before we were using the Password grant type.

I have done so by opening an in-app browser and going to the API, I have NOT user the Auth0.Swift or Lock.Swift libraries. Instead I have implemented it in mostly C# with Unity and using the advice given here and in the RFC standard https://auth0.com/docs/flows/guides/mobile-login-flow/add-login-using-mobile-login-flow.

Facebook and Auth0 allow me to login fine :slightly_smiling_face:
When I try Google login, I’m met with a 403 error: disallowed_useragent

Their documentation then goes on to suggest they do not approve of in-app browsers signing in with Google Id’s because it doesn’t take advantage of the native browsers cookies or other memory which might already have the user identity (from logging into another google service).

I’m not sure that’s actually true, from what I’ve seen on iOS, an in-app browser does essentially have access to the same native session data as the full Safari App, so I’m not sure what they’re talking about.

Anyway. I can see that your Auth0.Swift Sample does actually open an in-app browser, then even can login with Google!
How have you circumvented Googles disallowed_useragent error in the Swift sample? GitHub - auth0/auth0-ios-swift-sample

I think this is pertinent information which should be added to your Native PKCE login flow documentation because I did not know the user agent would be particularly important for the PKCE flow.

Cheers,
Jesse

2

Hi Jesse. There are two ways of letting users authenticate using a browser-based (interactive) flow:

  1. Putting a “webview” browser, hosted by your app.
  2. Asking the OS to open the system browser so that the user can complete what’s needed, and then return the result back to the application.

Alternative 1 is the one Google dislikes. And it’s very likely that you’ll see this restriction implemented by others in the future. When an app hosts a browser view in-process, it can do things that are just terrible from a security perspective, like spy on the credentials the user is typing, or accept the consent prompts presented by the authorization server without the user knowing. Any technically savvy user would frown upon having to enter their Google (or any other IdP) credentials into an app, with good reasons.
Alternative 2 is the one to use. You ask the OS to open a system browser for you, navigate to the provided URL, and relay the results back to the application after the flow is finished (this is done by monitoring the browser until it reaches the callback URL).
How you do it depends on the platform. iOS has ASWebAuthenticationSession for iOS 12.0+, and other class (like SFAuthenticationSession and SFSafariWebSession) for earlier versions. Check here if you are curious: Auth0.swift/SafariAuthenticationSession.swift at 294c63ae5ddbea1d4a6105088de3da11946bf156 · auth0/Auth0.swift · GitHub

In Android, this is by the “Web Broser” intent.
Here you can see how the Xamarin+Android in the Auth0 OIDC client SDK does it: https://github.com/auth0/auth0-oidc-client-net/blob/master/src/Auth0.OidcClient.Android/PlatformWebView.cs

2 Likes
3

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.