[ERROR] FusionAuth's login page redirecting issue on Android
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?
FusionAuth's Version: 1.19.8
Are you using custom pseudo-protocol scheme in the app redirect URL?
Sorry for the delay. Yes, we are using pseudo URLs.
Is there anything we can try?
dan last edited by
@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.
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.appas a scheme for your app, and then type in mobile web browser
com.company.app://whateveryour app will be launched - this works both on iOS and Android. But if you try to assign such url as an OAuth2
redirect_uriit 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 (
302response ...) 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
httpsschema) 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
httpsschemas... 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
Some additional insights on the matter can also be found in this issue in okta-sdk-appauth-android
@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.