MFA, passkeys, sessions and passwordless login
These features protect users of your application. Check integration availability first: several standalone security endpoints have an authentication limitation. Confirm the intended flow works before requiring MFA or passwordless login for your users.
This page describes application features that a developer must integrate. Changing your own dashboard MFA settings does not add these flows to your app. If you are testing SyAuth without an app, finish the basic hosted-login test first; the callback receiver does not implement MFA enrollment or passkeys.
| Feature | What the user should experience | What must be completed |
|---|---|---|
| Authenticator MFA | An extra current-code prompt during sign-in | Enrollment, confirmation, then a later login challenge completed by the app |
| Passkey | A browser/device prompt to register or use a credential | The app's begin/browser-prompt/finish sequence on a supported origin |
| Passwordless email | A sign-in code arrives in the user's mailbox | Request, delivery, code submission and any required MFA challenge |
| Session management | A view of sign-ins with a way to revoke a selected session | Authenticated session listing and the intended revoke operation |
Authenticator apps and recovery codes
An authenticated user starts TOTP enrollment, adds the returned secret/otpauth_uri to their authenticator, then confirms device_id with a current code. Enrollment is incomplete until confirmation succeeds.
A subsequent login can return mfa_required, mfa_ticket, and available methods. Submit the ticket and current code to complete sign-in. A recovery code can be supplied in the code field; it is single-use. Regenerating recovery codes invalidates the previous set. Generating recovery codes alone does not activate a primary MFA factor.
Passkeys
Registration follows begin → browser navigator.credentials.create() → finish. Sign-in follows primary authentication/ticket → begin → navigator.credentials.get() → finish with the same ticket. Use the WebAuthn payload specified by the API and Base64URL-encode binary credential fields.
Browser origin, relying-party ID and challenge must match the enabled deployment. Use HTTPS and a supported browser. An expired or already-used challenge requires a fresh attempt. Confirm support for your intended application origin before rollout.
Passwordless email
Request a sign-in code with email and client context, receive it by email, and consume it once. Generic request responses do not confirm whether an account exists. A user with MFA may still need to complete a challenge before receiving tokens.
Sessions
Application session APIs list recent sessions, revoke one, or revoke other sessions while preserving the current one when it can be identified. They are separate from dashboard sessions and OAuth token revocation. Do not assume one revoke operation ends every credential type.
See MFA/passkey/session requests, email sign-in and security anomalies.
For each feature, check the complete experience with a test user before treating setup as finished. An enrollment response or a browser prompt alone does not complete sign-in. If a documented endpoint returns an unexpected 401, check its availability note and collect the exact failing request/status; repeatedly changing passwords or adding a developer token does not resolve that documented limitation.