Email Verification

Email verification is a multi-factor authentication method. When enabled, users must enter a one-time verification code sent to their bound email address after correctly entering their account password, adding an extra layer of security to the login process.

Path: Console → Enter a specific application → Top navigation 「Configuration」 → 「Security Settings」 → 「Multi-Factor Authentication」

 

1. Application Configuration

1.1 Enable Email Verification

In the “Factor Management” section, find the “Email Verification” card and toggle the switch on.

Once enabled, users under this application will be required to perform secondary verification when logging in (only affects password login; third-party login and verification code login are not affected).

After changing the switch state, click the “Save” button at the bottom of the page for the configuration to take effect.

1.2 Disable Email Verification

Toggle the switch off, then click “Save”.

Before disabling, a pop-up will warn: if users have already bound email verification, disabling will remove all bindings irreversibly. Confirm to disable the factor.

Note: Multiple factors (e.g., email verification and OTP) can be enabled or disabled independently without affecting each other.

1.3 Customize Email Template (Optional)

When email verification is enabled, you can customize the content of the secondary verification email sent to users.

• Path: Branding → Email → Email Templates → Find the “Login Secondary Verification Code” template.
• Supports custom subject and body with variables:

  • {{application_name}}: Application name

  • {{email}}: User email

  • {{code}}: 6-digit verification code

• After editing, click “Save” to apply. You can also click “Save and Send Test Email” to send a test to your own RootAuth email.

Note: To change the sender email, first configure your own SMTP service under Branding → Email → Third-Party Email Service.

 

2. User Authentication Flow (Application Users)

2.1 Prerequisite

The application has enabled email verification.

2.2 Login Process

1. The user enters email + password on the application login page and clicks Login. (You can test the flow via the “Preview Registration/Login” entry.)

2. After verifying the credentials, if email verification is enabled and the user has a bound email, the system redirects to the secondary verification page.

3. The page automatically sends a 6-digit verification code to the user’s bound email (no manual “Send” click required for the first code).

4. If the user does not have a bound email, they must bind an email first and then manually request the verification code.

5. The user enters the received verification code and clicks “Confirm”.

6. Upon success, the user is logged in and redirected to the application callback URL.

If other verification factors are also enabled, the user can switch between methods using tabs on the secondary verification page.

2.3 Resend Verification Code

• If the user does not receive the email within 60 seconds or the code expires, they can click “Resend”.

• The button enters a 60‑second countdown; it becomes clickable again after the countdown ends.

2.4 Verification Code Rules

• Code validity: 10 minutes.

• If the same IP sends more than 60 codes within 1 hour, a security policy is triggered.

• After 6 consecutive incorrect code attempts (cumulative across enabled factors), the account will be locked for 1 hour.

 

3. Management in User Details Page

Administrators can view and manage a user’s email verification binding status.

Path: User Management → User List → Click the user’s email to enter details → Find the “Multi-Factor Authentication” module.

• View: If the user has bound email verification, their masked email address will be shown.

• Global bypass switch (Disable/Enable user MFA): Shared with other verification methods. When disabled, the user bypasses all MFA (including email and OTP). When enabled, the user reverts to following the application’s MFA configuration and must perform secondary verification on next login. If the application toggles a factor off and on again, the user will need to re‑bind OTP.

Email binding cannot be directly removed by an administrator; only the user can unbind it in their personal center. However, the global MFA bypass switch controls whether the user is required to perform secondary verification.

 

4. Logs and Auditing

After enabling email verification, user activity logs record related events:

• Event type: Secondary authentication - email

• Recorded fields: User, IP, country, time, result (success/failure), failure reason.

You can view these records under Audit Logs → User Activity Logs.