D.8 Email Link Authentication

Authenticate with Firebase Using Email Link

You can use Firebase Authentication to sign in a user by sending them an email containing a link, which they can click to sign in. In the process, the user's email address is also verified.

There are numerous benefits to signing in by email:

• Low friction sign-up and sign-in.
• Lower risk of password reuse across applications, which can undermine security of even well-selected passwords.
• The ability to authenticate a user while also verifying that the user is the legitimate owner of an email address.
• A user only needs an accessible email account to sign in. No ownership of a phone number or social media account is required.
• A user can sign in securely without the need to provide (or remember) a password, which can be cumbersome on a mobile device.
• An existing user who previously signed in with an email identifier (password or federated) can be upgraded to sign in with just the email. For example, a user who has forgotten their password can still sign in without needing to reset their password.

Enable Email Link sign-in for your Firebase project

To sign in users by email link, you must first enable the Email provider and Email link sign-in method for your Firebase project:

1. In the Firebase console, open the Auth section.
2. On the Sign in method tab, enable the Email/Password provider. Note that email/password sign-in must be enabled to use email link sign-in.
3. In the same section, enable Email link (passwordless sign-in) sign-in method.
4. Click Save.

Send an authentication link to the user's email address

To initiate the authentication flow, present the user with an interface that prompts the user to provide their email address and then call sendSignInLinkToEmail to request that Firebase send the authentication link to the user's email.

1. Construct the ActionCodeSettings object, which provides Firebase with instructions on how to construct the email link. Set the following fields:

• url: The deep link to embed and any additional state to be passed along. The link's domain has to be whitelisted in the Firebase Console list of authorized domains.
• androidPackageName and IOSBundleId: The apps to use when the sign-in link is opened on an Android or iOS device. Learn more on how to configure Firebase Dynamic Links to open email action links via mobile apps.
• handleCodeInApp: Set to true. The sign-in operation has to always be completed in the app unlike other out of band email actions (password reset and email verifications). This is because, at the end of the flow, the user is expected to be signed in and their Auth state persisted within the app.

var settings:ActionCodeSettings = new ActionCodeSettings("https://example.com/");
settings.dynamicLinkDomain = "yourURLPrefix.page.link";
settings.handleCodeInApp = true; // The sign-in operation has to always be completed in the app.
settings.iOSBundleID = NativeApplication.nativeApplication.applicationID;
settings.androidPackageName = "air." + NativeApplication.nativeApplication.applicationID;
settings.androidInstallIfNotAvailable = false;
settings.androidMinVersion = "1";

To learn more on ActionCodeSettings, refer to the Passing State in Email Actions section.

2. Ask the user for their email.
3. Send the authentication link to the user's email, and save the user's email in case the user completes the email sign-in on the same device.

Auth.listener.addEventListener(AuthEvents.SEND_SIGNIN_LINK_RESULT, onSignInLinkResult);
Auth.sendSignInLinkToEmail("[email protected]", settings);

function onSignInLinkResult(e:AuthEvents):void
{
	if(e.result == Auth.RESULT_SUCCESS)
	{
		trace("onSignInLinkResult email sent");
	}
	else
	{
		trace("onSignInLinkResult: " + e.msg);
	}
}

Complete sign in with the email link

Security concerns
To prevent a sign-in link from being used to sign in as an unintended user or on an unintended device, Firebase Auth requires the user's email address to be provided when completing the sign-in flow. For sign-in to succeed, this email address must match the address to which the sign-in link was originally sent.

You can streamline this flow for users who open the sign-in link on the same device they request the link, by storing their email address locally when you send the sign-in email. Then, use this address to complete the flow.

After sign-in completion, any previous unverified mechanism of sign-in will be removed from the user and any existing sessions will be invalidated. For example, if someone previously created an unverified account with the same email and password, the user’s password will be removed to prevent the impersonator who claimed ownership and created that unverified account from signing in again with the unverified email and password.

Also Make sure you use an HTTPS URL in production to avoid your link being potentially intercepted by intermediary servers.

Notice: Firebase Authentication uses Firebase Dynamic Links to send the email link to a mobile device. For sign-in completion via mobile application, the application has to be configured to detect the incoming application link, parse the underlying deep link and then complete the sign-in. To be able to read the deeplink being sent to your app when the emailLink is clicked, you need to have the DynamicLinks ANE ready in your app.

Verify link and sign in

After you receive the link as described above, verify that it is meant for email link authentication and complete the sign in.

var emailLink:String = "you have this from dynamicLinks when app was invoked with an emailLink";
if(Auth.isSignInWithEmailLink(emailLink))
{
	var email:String; // retrieve this from wherever you stored it
	
	// listen to SIGN_IN_RESULT like how you did for other signin methods
	Auth.listener.addEventListener(AuthEvents.SIGN_IN_RESULT, onSignInResult);
	
	Auth.signInWithEmailLink(email, emailLink);
}

To learn about how to handle sign-in with email link in a web application, refer to the Web guide.

Linking/re-authentication with email link

You can also link this method of authentication to an existing user. For example a user previously authenticated with another provider, such as a phone number, can add this method of sign-in to their existing account.

The difference would be in the second half of the operation:

// create a new authProvider object first
var authProvider:AuthProvider = new AuthProvider();
authProvider.setEmailLinkAuthProvider(email, emailLink);

// Link the credential to the current user.
FirebaseUser.listener.addEventListener(FirebaseUserEvents.LINK_WITH_RESULT, onLink);
FirebaseUser.linkWithCredential(authProvider.getCredential());

function onLink(e:FirebaseUserEvents):void
{
	trace("onLink result=" + e.result, "     msg=" + e.msg);
}

The same logic can also be used to re-authenticate an email link user before running a sensitive operation using the FirebaseUser.reauthenticate method.

However, as the flow could end up on a different device where the original user was not logged in, this flow might not be completed. In that case, an error can be shown to the user to force them to open the link on the same device. Some state can be passed in the link to provide information on the type of operation and the user uid.

Differentiating email/password from email link

In case you support both password and link-based sign in with email, to differentiate the method of sign in for a password/link user, use fetchSignInMethodsForEmail. This is useful for identifier-first flows where the user is first asked to provide their email and then presented with the method of sign-in:

Auth.fetchSignInMethodsForEmail("[email protected]", function ($methods:Array, $error:Error):void
{
	if($error)
	{
		trace("fetchSignInMethods: " + $error.message);
	}
	else
	{
		trace("fetchSignInMethods: " + $methods);
	}
});