Android: OTP auth browser closes when minimising app

[kimdanielarthur-cowlabs]

Checklist

• The issue can be reproduced in the react-native-auth0 sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

When authorising with email OTP on Android the browser here the user enters their authentication details will be closed if the user minimises the app and returns.

This is a typical usage scenario when the user needs to check their email app for OTP password.

I have seen a variety of issues related to this from some years back, all of them closed. But the issue seems to be present still.

Reproduction

Reproduced in the samples app

1. authorize({connection:"email"})
2. See web browser for otp signin
3. Enter email
4. Minimize android app
5. check email app for code
6. Open android app
7. See that browser for entering code is no longer visible

Additional context

The issue is reproducable in the minimal samples project

Note the samples app was modified to use latest package versions:

"dependencies": {
"@babel/runtime": "^7.24.7",
"expo": "~51.0.11",
"expo-splash-screen": "~0.27.5",
"expo-status-bar": "~1.4.0",
"react": "18.2.0",
"react-dom": "18.2.0",
"react-native": "0.74.2",
"react-native-auth0": "^3.2.1",
"react-native-web": "~0.19.2"
},

react-native-auth0 version

3.2.1

React Native version

0.74.2

Expo version

51.0.11

Platform

Android

Platform version(s)

14

[kimdanielarthur-cowlabs]

Has anyone else experienced this or is it just me? Seems to happen in basic example project so would assume its universal, or is there some additional intent configuration needed to fix this maybe?

[freethejazz]

We ran into something like this and changing the .MainActivity's launch mode to singleTop in AndroidManifest.xml helped us.

[mateoguzmana]

We are experiencing the same. Changing the launch mode to singleTop fixes this issue but it introduces a buggy behaviour with the deep links where it opens a new instance of the application. So it doesn't seem like a viable solution. Wondering if somebody faced this as well

[kimdanielarthur-cowlabs]

We ended up stopping the use of web browser for OTP login and rather using the flow through Auth0 api:

auth0Instance.auth
            .passwordlessWithEmail({
                email: otpEmail,
                send: "code",
            })
            
auth0Instance.auth
            .loginWithEmail({
                email: otpEmail,
                code: otpCodeEnteredByUser,
            })

This also fixed some other Android issues when using the Auth0 api hooks and authenticate() flow through web browserwhere Credentials fail be set on first login attempt due to an error related to "Lock screen code has changed" (although it has not...)

[freethejazz]

@mateoguzmana Do you recall how to reproduce the buggy deep link behavior? We're still testing the change but haven't seen anything like that yet. We're using @react-navigation/native at version ^6.0.2 and have tested opening both deep links and universal links after completing the auth flow, as well as before and after triggering share extension handling. We have yet to see any duplicate instances of the app.

EDIT: We did end up running into a problem where the app wouldn't load from a deep/universal link when the app was totally closed. It worked fine when tapping a deep/universal link while the app was in the background, but would just show a blank screen with our primary app color for a moment then shut down when the app's previous state was "closed".

[mateoguzmana]

@freethejazz good to know if works good for you! our reproduction path was quite simple:

• open the app
• move it to the background
• open a deep link
• you will see two instances of your application

We are still investigating the culprit of this as well though. Perhaps it is something else related to our configuration. We are using @react-navigation/native at version ^6.0.6.

[mateoguzmana]

I may have found a better lead to this issue. It seems like other libraries have faced the same, and there is a good workaround for this.

I am not an Android expert but what I understood after all this research: By default if you use singleTask, when you press on the app icon the main activity relaunches as well. So if you have the Auth0 browser open for example, this would close it as it is not the main activity.

To address the above, you can wrap your main activity with another activity that checks whether the main activity has been launched or not and then prevent re-launching it. Which helps keeping any other activity open and any other library depending on singleTask doesn't get affected as the main app behaviour doesn't change.

See:

• stripe-react-native – Android Chrome Tab Closes on Background
• Similar issue in react-native-inappbrowser

I implemented the fix on our side, and everything seems to work as expected now, including deep links. We will continue testing for any possible side effects of this solution, but so far it looks very promising. I wanted to share this update here in case it helps anyone.

[freethejazz]

@mateoguzmana Thank you for sharing, very helpful! We looked into the links you shared and have implemented the fix ourselves and it's seemed to resolve all of our issues as well.

Given the in-app browser/universal login approach seems to be the recommended path by Auth0, and that handling deep links is such a common use case, I would propose that the Auth0 team consider adding this workaround as part of the android setup steps in this library's docs.

@poovamraj: I've seen you've been an active contributor on the android side of this project and other android Auth0 projects. Would you be the right person to review this?