Why is this implemented and what is possible as an alternative?

[nall-near]

Currently there is a flow for FastAuth that requires a user to input their email address into a floating form before their account can be recovered/created:

User Flow

1. Enter Email
2. Send verification message
3. Open Link within message
4. Browser opens with field requesting user's email
5. User enters email and is redirected back to site (not sure if it logs them in or not?)

I believe this was a hack used originally to mitigate requests from email clients opening in different browsers, but I'm unsure of the full technical details.

Main Questions

1. Why is this required and have we done anything to resolve its original intent?
2. What alternatives are possible that can be used to remove this step from the flow?

[trechriron]

@nall-near Since you asked a question on the original defect, can we close this? I don't feel it's necessary to track a separate ticket.

[nall-near]

Hey @trechriron , I haven't gotten a response yet so this is one I wanted to turn into a discussion topic so I could get more input. Whatever you think. Instead of posting long discussion topics in Slack I'd rather them live here in GitHub. Take Corwin's example here

[esaminu]

This happens because the user’s email is stored in localstorage so if you open a new browser / device we can’t retrieve it and we have to prompt the user to re enter. This is per the firebase docs (Step 3).
Sending the email address as a query param would resolve this but is a security issue as outlined in https://firebase.google.com/docs/auth/web/email-link-auth#security_concerns. If you open the verification link in the same browser and device, you will not be prompted to re enter your email address

[nall-near]

@esaminu @MaximusHaximus a few questions:

1. Is there a reason the confirmation needs to happen in a native browser UI context, or can we prompt for confirmation in the signer app?
2. Is there a way to sign in to the original session if the verification is completed in a different session? Currently we abandon the original session, no change to sign in status.
3. Have we explored using an session ID to track the session, or some fancy URL stuff to try to launch in the original session?
4. Is it even possible to use a PIN code approach with Firebase or would it be some custom implementation? What is the effort required?

[nall-near]

Can we use dynamic links to attempt to open in the originating browser? Reference
After user successfully opens the link, can we consider the email "verified" regardless if the briwser and prompt them to return to their original session?