AUTHENTICATION METHODS · LAB
Count factors in amr, not screens
Produce four real sign-ins with different evidence and decide from the ID token's amr alone which ones were multi-factor.
ReadyUses your lab tenant
The lesson
Builds on: Codes, links, and approval prompts.
New to the labs? Start with the lab toolkit and the shared cast and names every lab uses.
Your progress
Press Start before you begin. Only events your tenant records after that count, in the order below. Checking reads your tenant's Audit, so you need Audit read access in it.
Sign in to start this lab and check your progress. Log in or create an account.
Complete a password and authenticator sign-in
Recorded as
account.second_stepsucceeded (second_step_completed).Sign in with a verified passkey on one screen
Recorded as
account.sign_insucceeded (signed_in).Fail a required second step after a correct password
Recorded as
account.second_steprejected (invalid_code).Restore required user verification
Recorded as
tenant.authentication.updatesucceeded.
Setup
Complete Sign in by email link, email code and authenticator code first. Mia then has a password, email methods and an authenticator app.
In Authentication, check that the second step is
enrolledand remember-device is 0 days. Set passkey user verification to Preferred for this lab only, and save.In Mia's private window in Chrome, open DevTools WebAuthn, enable the virtual authenticator environment, and add a CTAP2 authenticator that supports resident keys and user verification. Sign in as Mia, open
$ISSUER/account/securityand register it as a passkey.Prepare a table with the columns journey, screens,
amr, and MFA.
Walkthrough
For each row, sign Mia out at $ISSUER/account, sign in the way described at $ISSUER/login, then open $ISSUER/token-decoder and copy amr from the ID token into your table.
Password, then the authenticator app as the second step.
amris["pwd","otp","mfa"]. Two screens, two kinds of evidence.
Why it matters: knowledge plus possession of the app's secret, both accepted for this attempt, is the lesson's example of MFA.
Email sign-in link, then the authenticator app.
amris["email","otp","mfa"]. On the second-step page, notice that the email code is not offered after an email link.
Why it matters: an email link and an email code both prove access to the same mailbox. Two mailbox checks would prove the same thing twice, so the tenant never pairs them.
The virtual passkey, with user verification on. One screen, and
amris["hwk","mfa"].
Why it matters: one interaction can carry two factors when the authenticator verifies the user locally. The device count is one; the factor count is two.
In DevTools clear Is user verified, then sign in with the virtual passkey again. Because the policy now only prefers verification, the response is accepted, and the tenant asks for a second step. Use the authenticator app.
amrcontainshwkandotp, but nomfa.
Why it matters: a key used with a touch and an authenticator app are two things to steal, but both are possession. The tenant asks for the second one and does not claim MFA.
Compare rows 1 and 4. Both took two screens. Only row 1 combined two factor types.
Why it matters: count factors, not screens. An application that needs MFA must read mfa in amr, and must treat a missing value as no MFA, never as unknown-but-probably-fine.
Fill in the phishing column for each row: which ones could a fake page relay? Rows 1, 2 and 4 depend on something Mia types or opens; row 3 is bound to the tenant's origin.
Why it matters: passwordless, multi-factor and phishing-resistant are three different properties. Row 2 is passwordless but not phishing-resistant; row 3 is all three.
Break it
Sign out, sign in with Mia's correct password, and at the second step enter a wrong authenticator code. The tenant refuses it and Mia has no session.
Why it matters: the correct password does not survive a failed required check. The failure may mean that someone else knows the password, so the attempt fails as a whole.
Restore: in Authentication, set passkey user verification back to Required and save.
Check your work
Press Check my progress. The checks follow the password and authenticator sign-in, the one-screen passkey sign-in, the failed second step and the restored setting.
Also confirm by hand:
Your table has four
amrvalues, and only rows 1 to 3 containmfa.
Cleanup
In
$ISSUER/account/security, sign in again if asked and remove Mia's virtual passkey. Then remove the virtual authenticator in DevTools.Passkey user verification is back to Required from the restore step.