Configure the Email authenticator

The Email authenticator provides two methods for users to authenticate or recover their access to their account:

Click an email magic link.
Use a six-digit verification code as a one-time password (OTP).

The Email Magic Links overview in the Okta developer documentation explains the email magic link and OTP concepts and the differences between them.

Okta sends these authentication methods in a message to the user's primary email address. The user's ability to access the email verifies that the person making the sign-in attempt is the intended user.

This method provides a simple way for users to authenticate, but there are some issues to consider if you implement the email authenticator:

If the user doesn't click the email magic link or use the OTP within a set time, their authentication isn't processed.
Email isn't always transmitted through secure protocols. Unauthorized third parties can intercept unencrypted messages. Consider assigning a shorter challenge lifetime to your email magic links and OTP codes to mitigate this risk.
Networking issues can delay email messages. If the authentication email arrives after the challenge lifetime has expired, users must request another authentication email.
Email messages can arrive in the user's spam or junk folder. Remind your users to check these folders if their authentication email doesn't appear.

Add the Email authenticator

For both redirect (Okta-hosted) and embedded authorization flows, you need to add the Email authenticator to the org:

In the Admin Console, go to SecurityAuthenticators.
On the Setup tab, click Add authenticator.
Click Add on the Email tile.
Optional. Change the default Email challenge lifetime (minutes).
The default value is five minutes, but you can increase the value in five-minute increments, up to 30 minutes. The accepted best practice is 10 minutes or less. If an end user clicks an expired magic link, they must sign in again.
In addition to email challenge links for authentication, Okta also applies this expiration value to self-service password resets and account unlocks.

You can configure Okta to use this authenticator for just account recovery, or for both authentication and account recovery. If you choose only the recovery option, Okta doesn't request authentication during the evaluation of your Global Session Policy.

Select the scenarios for which end users can use the email authenticator:
- Authentication and recovery
- Recovery
Click Add.

If you’re using embedded authorization for your sign-in flow, you must follow the Integrate Magic Links procedures outlined in the Email Magic Links overview.

End-user experience

When an end user attempts to sign in, reset their password, or unlock their account, Okta sends an email containing a magic link and a one-time password (OTP) code. The end-user documentation describes how to sign in with an email magic link or one-time password.

Sign-in attempt

If the end user clicks the email magic link in the same browser and the authentication flow doesn't require any subsequent factors, it automatically signs them in through a newly opened tab in the same browser. The session ends in the original browser tab.

However, the experience is different if the end user receives or opens the magic link email on a different browser or device. They must return to the original browser and click Enter a verification code instead. Then they can enter their OTP code to complete the verification process.

After the end user is verified by the authentication flow, it redirects the end user to the destination configured for the application:

If the end user was attempting to sign in to Okta, the browser opens their Okta End-User Dashboard.
If the end user was signing in using an embedded authorization flow, it redirects them to the location specified by the Email Verification Experience setting. See Configure settings for app integrations.

Password reset

For a password reset, clicking the link in the email sends the end user to a new tab where Okta asks them to verify that they made the request. When they affirm the request, the flow ends in the original browser tab, and they can set a new password in the new tab. If the password meets the acceptance criteria, the end user clicks Back to sign in to return to the sign-in page. If the end user clicks Enter a verification code instead, they can set a new password in the same tab, after which the sign-in action completes.

The following flow applies if your org was created after the 2022.10.0 release or if you activated the Self-Service Password Reset early access feature.

For a password reset, if the end user clicks the email magic link using the same browser where they received the email, the link opens a new tab where Okta asks them to enter and verify a new password. If the password meets the acceptance criteria, the end user is signed in automatically with the new credentials through the newly opened tab in the same browser. The session ends in the original browser tab.

Account unlock

When unlocking an account, clicking the link in the email sends the end user to a new browser tab for verification. After they affirm the request, the flow ends in the new browser tab, and they can click Back to sign in on the original browser tab. If the end user clicks Enter a verification code instead, they enter the code in the original browser tab, after which the unlock action completes and they can click Back to sign in.

However, if the end user receives or opens the email magic link on a different browser or device, they must return to the original browser and click Enter a verification code instead. Then they can enter the OTP code provided in the email to reset their password and complete the verification process.

The following flow applies if your org was created after the 2022.10.0 release or if you activated the Self-Service Account Unlock early access feature.

For an account unlock, if the end user clicks the email magic link using the same browser where they initiated the unlock request, the link opens a new tab where Okta asks them to proceed with the next steps. The end user must complete any step-up operations required by the unlock request. Clicking the email link and any step-up verifications completed by the end user are counted as verification criteria.

If the end user meets all the acceptance criteria, they are signed in to the application in that same tab of the browser. The session ends in the original browser tab.

Limitations

Okta always sends the authentication email to the end user's primary email address.
If the end user has access to the Okta End-User Dashboard and the Okta End User Settings page, set the primary email address in the user profile to be a read-only attribute. Any changes to an end user's primary email address automatically enrolls them in a new email authenticator and sends any emails to their new address without additional confirmation.
The Email authenticator is automatically enrolled for both authentication and recovery flows when a user verifies their primary email address, or if you provide the primary email address when you create the user account. This ensures that the user doesn't receive redundant email enrollment challenges if they already proved they own the email address, such as after self-service registration, or if they aren't required to prove they own the email address, such as when the admin creates the user account.