[Question] Firebase UI sign in flow unsuccessful with TWA

[peterpeterparker]

Question in detail In our application, we are using Firebase and have implemented Firebase UI - web to handle the sign in flow.

We are using the sign-in flow `redirect.

The registration and sign-in are working as expected on desktop and on mobile as well (in the browser or installed) using our PWA.

Unfortunately, when trying the exact same sign-in flow using the app I get from Google Play I am not able to sign-in using social (Gmail or GitHub) method.

Indeed, once I grant the login in the third party social service, I am redirected to the app but instead of reusing the same activity, it seems that the app, the TWA, is briefly rebooting. Therefore, the signin flow fails and I am not able to signin.

Is your question related to a problem? Please describe. I am asking a question because I am not sure if it is a general issue with Android or actually something which can be improved in the TWA provided by PWA Builder (that would be awesome 🤞),

Describe alternatives you've considered Right now not much. I am a bit unsure about the root cause of the issue (Android or TWA).

Screencasts I have paired my phone with the Chrome debugger. As you can notice, with the PWA, the debugger remains connected, the activity is the same.

To the contrary, using the TWA, the Chrome Debugger gets disconnected because the app is rebooting.

[ghost]

Hello peterpeterparker, thank you for your interest in PWABuilder!

I have automatically added a "needs triage" label to help get things started. Our team will look into the question and answer ASAP. Other community members may also answer the question and provide feedback 🙌

[lee-leonardo]

@peterpeterparker, unfortunately @JudahGabriel who is are Android expert is currently on leave. This seems like a lifecycle problem to me at prima facie.

My hypothesis is twofold, the activity hosting the TWA is garbage collecting in the emulator implementing some details onPause hook in the host activity might be able to mitigate this behavior. The second aspect would be that the TWA is in a sandbox. The only way it seems to pass back information would be to manually passing the tokens back from the url or uri. This is because the TWA cannot communicate directly with an external browser instance.

https://developers.google.com/web/android/trusted-web-activity https://developer.android.com/guide/components/activities/activity-lifecycle#alc https://developer.android.com/topic/libraries/architecture/lifecycle#lc

Please let me know if it helps! Apologies for the bad news on MacOS. It's bothering me and I hope to return to that problem once we get our EoY goals in order ;)

[peterpeterparker]

Thank you for the detailed answer @lee-leonardo 🙏

With hybrid apps, Cordova, such web login method as Firebase UI for Web won't work and have to be implemented with plugins. Using TWA, I was hoping that since it is powered by the browser, that such functions would work too.

But, indeed, if there are several activities, even though the navigation occurs on the web, it seems that sign gonna be again a tricky challenge.

Speaking of, you are mentioning "communicate directly with an external browser instance", since the navigation is happening on the web (from the TWA to gmail and back to TWA) shouldn't/couldn't the navigation happens in the same instance? is there a settings to do so?

P.S:: No need to worry at all for MacOS. As I said in my original message, I just wanted to give it a try. Really appreciate the time you have spent on it, thanks a lot!

[lee-leonardo]

@peterpeterparker I am not an expert on this topic, but I believe where a Cordova app is pretty much some custom tooling that provides a web wrapper and tooling to help your application gain access to Android APIs. TWAs are a response to this by providing an option where it simplifies the communication of your application with the Android platform by simplifying the relationship between them. Rather than exposing the apis directly to your web app, the web app can send Android messages (intents) to the parent activity. Therefore your web application code can interact with the container via urls and uris. This approach might not seem intuitive, but by structuring communication it seems like they are trying to prevent abuse as well as follow an established pattern in Android development (messaging between applications via intents).

After some more research, I believe it possible to potentially allow this via Digital Asset links. So essentially you are giving Android explicit permission to pass information back and forth between your sandboxed instance of Chrome (TWA) and the actual Chrome app on the device.

https://developers.google.com/web/android/trusted-web-activity https://developer.chrome.com/docs/multidevice/android/intents/ https://developers.google.com/digital-asset-links/v1/getting-started https://developers.google.com/identity/smartlock-passwords/android/associate-apps-and-sites

However other than providing guidance for users, from my understanding we just provide a simple web API that wraps the Bubblewrap CLI, I'm not sure if we can do anything substantial on our end as the cli is Google. However, I do believe what you are trying to do is a task that would fit nicely as a tutorial and demo on our site to help users conceptualize and overcome this hurdle. I'll definitely push for a tutorial!

[peterpeterparker]

thank you @lee-leonardo for all the information 👍

Digital Asset links seems to be an interesting solution hypothesis, I should have a deeper look and of course, I find the idea of tutorial really, really interesting. I can't imagine that I am the only one who use a PWA/TWA with a sign in method, moreover while using Firebase Web UI. I can think it can be useful to some, I guess.

[davrous]

Great discussion. Adding @andreban so he can share his feedback on this authentication issue.

[andreban]

Hi everyone, checking if I understand what's happening correctly:

1. User starts TWA
2. Clicks on Login, which opens a "minimal UI" mode.
3. After login, user is redirected to the original page.

Could you give us more insights on the dependency dependency on the initial page and the redirect page? It seems when redirected there's a dependency on state (session cookies, session storage?).

I do think in this case everything happens inside Chrome and the host (Android) app is not involved. @peconn may have more insight on what's happening.

[peterpeterparker]

I'll try to reproduce it with a minimal sample app so that it will make it easier to understand to everyone.

Also hopefully I'll not notice that I'm the root cause of the issue 😅.

It might take a couple of days. I'll ping this thread when the info when done.

[peterpeterparker]

I am able to reproduce the issue with a minimal sample repo and here are all the information:

• Sample repo: https://github.com/peterpeterparker/firebase-ui-twa

It's a Stencil app. All the code finds place in app-home.

Note: I inject the Firebase UI when the component is mounted aka it is not part of the bundle. It reflects my real use case. To the contrary the Firebase lib is part of the bundle.

• PWA

The PWA is deployed online (Firebase hosting) and can be tested at https://github.com/peterpeterparker/firebase-ui-twa

• TWA

You can download the TWA zip package generated by the PWA Builder here.

To give a try on your Android phone, you can use the .apk file (Stencil.apk)

Note that if you have tested the sign in with the PWA before trying out the TWA, you would need first to sign out. I did not implement much logic beside "sign in / sign out".

A word about privacy: I created a Firebase app to test this authentication. Once the issue closed, I will of course delete it, you have my word.

[peterpeterparker]

@andreban the flow is the following

1. User starts TWA
2. Click "sign in with a 3rd party social provider" (such as gmail) with Firebase ui
3. User is redirect to 3rd party
4. User accept and grant access
5. User is redirected to TWA
6. Sign in the TWA fails

[andreban]

Thanks for the whole repro app! Checking it out today!

[andreban]

I deployed the sample to https://fir-ui-twa-signing.web.app/ and added a valid Digital Asset Links. It does seem to work as intended when the Digital Asset Links validation works (see attached video).

I can reproduce the error when the Digital Asset Links validation fails. The behaviour is a bit awkward, but given the app is in a broken state when Digital Asset Links fails, I don't think a priority.

Having said that, I'm wondering if there's any other different in my implementation that may explain the behaviour you are seeing.

https://user-images.githubusercontent.com/1733592/103910309-98c59b80-50fc-11eb-9705-d89132ee0273.mp4

Here's the APK: app-release-signed.tar.gz

[peterpeterparker]

@andreban that's really cool and begin to sound like the mistake is on my side with our app...

The only difference I notice spontaneously between our real app and the demo sample is that our app finds place in a sub-domain (https://app.deckdeckgo.com).

The Digital Asset Links should find place in the sub-domain in that case right?

The app used to be on the root domain and have been move recently. The package name did not change, therefore I did not generate a new asset links and only moved it to the subdomain aka I don't have any digital asset links file anymore on the root.

[peterpeterparker]

I have deployed a valid Digital Asset Links for my sample repo and indeed, I can confirm the finding of André it does solve the issue with my demo repo.

[peterpeterparker]

I've generated and deployed a new Digital Asset Links fingerprints for our app and it solved the issue.

I am guessing that even if I did not change the package name, since I moved it to a subdomain, I had to generate a new one 🤷‍♂️. Or it was broken since a long time and I noticed it only now 😅.

My gosh, I'm sorry for the support question. All my apologies for the long feed.

Thanks a lot @lee-leonardo and @andreban for your time 🙏.