Appearance
Multi-factor authentication
MFA is configured per tenant in the Sign-in Experience and enforced automatically during sign-in. Your application does not implement it — the OIDC flow is unchanged.
Supported factors
| Factor | What it is |
|---|---|
| Authenticator app (TOTP) | Time-based one-time codes (Google Authenticator, 1Password, Authy…). |
| Passkey / WebAuthn | Platform or roaming authenticators (Face ID, Touch ID, security keys). Phishing-resistant. |
| Backup codes | One-time recovery codes for when the primary factor is unavailable. |
Enable MFA
Admin console → Sign-in experience → Multi-factor authentication:
- Turn on the factors you want to offer.
- Choose the policy:
- Require MFA — every user must set up and use a factor.
- User-controlled — users may opt in; not enforced.
- Offer backup codes alongside a primary factor, not alone.
MFA settings are per tenant — each tenant configures its own.
The end-user flow
- Enrollment — on first sign-in after MFA is required (or opt-in), the user sets up a factor.
- Challenge — on later sign-ins, they're challenged after the primary credential.
- Management — users add/remove factors and regenerate backup codes in the account center.
For integrators
MFA happens entirely inside Authara. When MFA was used, a stronger amr (authentication methods reference) claim appears in the ID token — check it if your app needs to assert MFA occurred.
Best practices
- Prefer passkeys/WebAuthn — phishing-resistant and the best UX on modern devices. Offer TOTP as fallback and backup codes for recovery.
- Require MFA for privileged tenants/admins who can reach the Management API.
- Always pair a primary factor with backup codes so users can't get locked out.
- Keep lockout on — the Sentinel guard rate-limits and locks out repeated failed verification attempts.