Hi Jesse. There are two ways of letting users authenticate using a browser-based (interactive) flow:
- Putting a “webview” browser, hosted by your app.
- 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