Multi-factor authentication
Multi-factor authentication (MFA) asks a user for a second proof of identity after their password — a one-time code, or a passkey on their device. It blocks an attacker who has the password but not the user's phone or device. Like the rest of sign-in, MFA runs inside ID: ID prompts for the second factor during sign-in and only returns a token once the user clears it. Your app doesn't build MFA screens or verify codes.
How it fits the sign-in flow
MFA is a step ID inserts into the sign-in flow, between the password and the token:
1. Your app sends the user to ID's sign-in page.
2. The user enters their password (or signs in with a social provider).
3. If a second factor is required, ID prompts for it and verifies it.
4. ID redirects back to your app with a one-time code.
5. Your app exchanges the code for a token — same as any other sign-in.
The token your app receives is the same regardless of whether a second factor was used. There's nothing MFA-specific to handle in your code: if ID returns a token, the user has cleared every check ID required.
What ID supports
- Authenticator app (TOTP) — a time-based one-time code from an app like Google Authenticator or 1Password.
- Passkeys (WebAuthn) — sign in with a fingerprint, face, or device PIN, with no password at all. A passkey is phishing-resistant and can serve as both the first and second factor.
A user enrolls a second factor in their account settings at ID. Once enrolled, ID prompts for it on future sign-ins automatically.
Turning it on
Whether MFA is optional or required is a tenant policy, set with your platform administrator — not something your app toggles. A common setup is to require MFA for staff and administrators and leave it optional for customers. Talk to your administrator about the policy that fits your tenant.
Troubleshooting
- The user isn't prompted for a second factor — they haven't enrolled one, or your tenant's policy doesn't require it. Enrollment happens in the user's account settings at ID.
- The code is rejected — TOTP codes are time-based, so the device clock must be accurate. Have the user check their device time and try the current code.
- A user is locked out — a user who loses their second-factor device needs an administrator to reset it. Direct them to your support process; your app can't reset it.
What's next
- Sessions — the sign-in flow MFA plugs into.
- Social sign-in — let users sign in with an existing account.