[ERROR] FusionAuth's login page redirecting issue on Android

[marco]

Hey guys.

We are using FusionAuth's login page for our mobile application.

As our users are using the app, we found out that there is a redirecting issue when we log in using Google Provider on Android phones.

After the user is logged in (we think it is), the page keeps loading and waiting for a page redirection;

So we close the app and try to log in again, and the user is automatically redirected (because it is already logged in).

Can you guys help us out?

Video link: https://www.icloud.com/iclouddrive/0rJB--7z6KA_NI6iC1CgVsbBw#google_login_error

Other info:
FusionAuth's Version: 1.19.8

[mgetka]

Are you using custom pseudo-protocol scheme in the app redirect URL?

[marco]

Hey mgetka.

Sorry for the delay. Yes, we are using pseudo URLs.
Is there anything we can try?

Thanks!

[dan]

@marco any logs happening anywhere? You can turn on debugging for the Google Identity Provider and that will add more debug logs to the Event Log (under System in the admin UI) which may contain useful info.

[mgetka]

When you try to utilize social sign-on in your android application, the page is not loading forever, it is actually being blocked. Redirecting to mobile applications is actually quite tricky. It has been some time since I was working on that matter but I will try to provide with most important insights on the topic.

So mobile app can register pseudo protocol, and once mobile web browser reach url with such schema, the application will be launched. If you register com.company.app as a scheme for your app, and then type in mobile web browser com.company.app://whatever your app will be launched - this works both on iOS and Android. But if you try to assign such url as an OAuth2 redirect_uri it will work on iOS but not necessarily on Android.

The issue is related to chromium security policies on redirects, and since system browsers on android are based on chromium engine it affects web views and other web based modals.

If the user directly types the custom schema url in the browser it will be allowed since the request was directly initiated by the user. If the user logs in via login & password, a chain of events occur (POST request, 302 response ...) that results in a custom scheme redirect, and finally, the redirect will be allowed since direct user action was the initiator of the chain. In the case of social sign on, we could think that the chain leading to the redirect is also initiated by the user, but the magic standing behind the login widgets breaks the chain, and chromium thinks that the redirect was arbitrarily initiated by some scripts rather than the user, so it is being blocked. Here is a link to long living chromium issue if you wish to track how things evolved through the time.

Finally, chromium thinks custom schemas are evil and we need to live with that. But OAuth2 needs to work in todays web, so there is another way - deep linking. Long story short, an application can register some specific URL (with http/https schema) that will lead to opening of the application. Such redirects are not blocked, and indeed it is a recommended way to perform application redirects on android.

So to sum it up, on iOS use pseudo protocol, on android use deep linking with http/https schemas... Nooo, it still not that easy Deep linking is not supported by older android versions, and those older versions allows for pseudo protocol redirects. So if you want to support older android devices that don't receive software updates since some time, you need to use pseudo protocol for them.

So to sum it up (for real this time), on iOS and older androids use pseudo protocol, on recent androids use deep linking with http/https schemas.

In my application, to accommodate the possible combinations, I've chosen to redirect iOS users directly to pseudo protocol. And redirect all the android user to a custom interstitial site. The URL of the site is registered via deep linking, so newer androids will redirect to the app with no fuss. For the older devices, under the address there is a simple page trying to perform redirect to pseudo protocol via javascript. As a last resort, if the user stays on the page for some time (so the javascript redirect didn't succeed), a link like "go back to the app" appears that allows an user to directly initiate the redirect - and this will always works. Example of such an interstitial page can be found at
AppAuth-Demo.

Some additional insights on the matter can also be found in this issue in okta-sdk-appauth-android
repository.

[fanshaohua.fan]

@mgetka thanks so much for the explanation.

"to redirect iOS users directly to pseudo protocol. And redirect all the android user to a custom interstitial site. "
I believe this would be the only option for the time being.

Deep Linking doesn't work at least for my application:
Flutter -> flutter_appauth(4.0.1) -> fusionauth

While the same scenario could work with Auth0, following this blog.

Comparing with the solution with FusionAuth.
FusionAuth open a new tab for Facebook and Google login.

While Auth0 continues on the same page with a page redirection.