In Hosted Login v2, two-factor authentication (2FA) provides an additional layer of security: after supplying an email address and password, and after being authenticated, a user is sent an access code via email or text messaging. In turn, the user must supply that code before he or she is fully logged on and is issued an access token. 

📘

You’re right: thanks to trusted devices, a user might not have to supply a two-factor access code each time they log on. See Trusted devices for details.

For many organizations, the additional steps required when using 2FA are worth it: adding in a second authentication factor provides both peace of mind and an extra layer of security. For other organizations, however, 2FA’s additional requirements – logging on always requires ready access to your email account or your mobile device – might not be worth it. And that’s fine: two-factor authentication is entirely in Hosted Login v2, and can be enabled or disabled simply by toggling the value of the authentication.second_factor setting in your application client.

On the other hand, even organizations that don’t need two-factor authentication might want to use Hosted Login v2’s access code approach for verifying user email addresses: they’d prefer to use a 2FA-like approach to verify user email addresses during registration, and to ensure that users can’t log on unless they have a verified email address. But is that even possible: can you suppress 2FA for user logins (assuming that the user logging on has a verified email address) yet still use the 2FA approach for verifying email addresses? As it turns out, you can.

Hosted Login v2 introduces an updated authorization rule –  authorization.rules.email_is_verified – that employs the access code system to verify user email addresses, but without requiring users to provide an access code each and every time they log on. Here’s how the process works.

Let’s assume that you’ve decided not to enable 2FA but you have enabled the authorization.rules.email_is_verified authorization rule; let’s further assume that you have some users who have verified their email addresses and other users who have not. (Which is possible if you haven’t required verified email addresses up till now.) For example, suppose Maria Fuentes has verified her email address. After Maria enters her email address and password at the sign-in screen, Hosted Login checks to see if that email address has been verified. Because it has been, Maria is logged in and is issued an access token.

Skeeter Davis, on the other hand, hasn’t verified his email address. So what happens when Skeeter logs on? This is what happens: Skeeter enters his email address and password at the sign-in screen, and Hosted Login checks to see if his email address has been verified. In this case, it hasn’t been; the emailVerified attribute in Skeeter’s user profile is null:

Because of that, the authorization rules kicks in and Skeeter is not fully logged in and is not issued an access token. Instead, an access code is sent to Skeeter’s email address and the following screen is displayed:

Skeeter must retrieve the access code from his email, enter that code in the Enter your access code field, and then click Continue in order to finish his login and receive an access token. There’s no exception here: if you don’t verify your email address you won’t be logged on. Period.

So what happens the next time Skeeter logs in? Well, we know what doesn’t happen: he doesn’t have to enter an access code. And that’s because he now has a verified email address.

Enable email verification without enabling two-factor authentication

Before we go any further, keep in mind that the use of access codes is limited to Hosted Login v2. If you’re running Hosted Login v1, you can still require verified email addresses by using the authorization.rules.email_is_verified authorization rule. In Hosted Login v1, however, verification links are sent via email, and the user must click the link within the email in order to verify their email address. 

Which simply means that you can require verified email address in either version of Hosted Login. The difference lies in the way those addresses are verified: verification links (v1) vs. access codes (v2).

To enable email verification (something you can do even if two-factor authentication isn’t enabled), complete the following procedure in Console:

1. Click Manage Properties, click the Actions icon located next to the appropriate application client, and then click Edit:

   

   The “appropriate application client,” as you know, is the application client associated with your OIDC login client.

2. On the Edit Property page, scroll to the bottom of the page and then click Edit Settings:

   

3. On the Edit Settings page, click the Add Setting icon:

   

4. In the Select setting key field, type authorization.rules.email_is_verified and then click Create authorization.rules.email_is_verified:

   

5. Type true in the Value field and then click the Save Setting icon:

   

At this point, email verification is enabled and enforced for any users logging on with the associated OIDC login client.

📘

That’s fine: Hosted Login won’t revoke their access token or expire their user session. However, the next time they do log in they’ll need to verify their email address.

If you later change your mind and want to disable email verification, simply set the value of authorization.rules.email_is_verified to false.