AUTHENTICATION METHODS · LAB

Register and use a passkey bound to your tenant

Register a passkey for Ava, sign in without typing an identifier, and see the tenant reject a response without user verification.

ReadyUses your lab tenant

The lesson

Security keys, passkeys, and biometricsPractices Signing in with your device, Registering a key, Answering a challenge, Presence and verification, Where keys live

Builds on: Methods, credentials, and factors.

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.

Register a passkey for Ava
Recorded as account.security succeeded (method_enrolled) about [email protected].
Sign Ava in with the passkey and no identifier
Recorded as account.sign_in succeeded (signed_in) about [email protected].
Present a passkey response without user verification
Recorded as account.sign_in rejected (passkey_invalid).
Remove the test passkey
Recorded as account.security succeeded (method_removed) about [email protected].

Setup

You need a device with passkey support, a security key, or Chrome, whose DevTools can add a virtual authenticator (More tools > WebAuthn).
In the portal open Authentication and set Passkey or security key to Optional, user verification Required, attachment Any, passwordless on. Save.
Note the Token Decoder's client ID from OAuth > Clients. You need it as the audience in step 4.

Walkthrough

In Ava's private window sign in at $ISSUER/login with her password, open $ISSUER/account/security and add a passkey. Your device asks for a PIN or biometric. Save the recovery codes the page shows once.

Why it matters: the authenticator creates the key pair. The tenant validates the registration and stores only the public key and a credential ID. Adding a way into the account needs a sign-in from the last 10 minutes, so a borrowed session cannot quietly add a key.

Sign out and open $ISSUER/login. Choose the passkey option without typing an email address, and pick Ava's passkey.

Why it matters: a discoverable credential stores Ava's account handle with the private key, so the authenticator tells the tenant which account is signing in.

Open $ISSUER/token-decoder and sign in. Read amr: ["swk","mfa"] for a synced passkey, or ["hwk","mfa"] for one that stays on a device.

Why it matters: the tenant reports where the key lives and that the device verified the user, so one interaction carried two factors.

Copy the ID token from the Token Decoder and validate it yourself:

read -rs ID_TOKEN
btl-lab verify "$ID_TOKEN" --issuer "$ISSUER" --audience "<Token Decoder client ID>" --type id --no-nonce

Every check passes: signature against the tenant's JWKS, issuer, audience and lifetime.

Why it matters: an application relies on the tenant's signed result, not on the fingerprint. The biometric never left the device, and the tenant never received it either.

Optional, the relying party binding. In Lab Mail ($ISSUER2), turn passkeys on in Authentication, then open $ISSUER2/login in Ava's window and choose the passkey option. Ava's Lab Photos passkey is not offered.

Why it matters: the credential is bound to the Lab Photos host name. A different origin, including a lookalike, cannot ask the browser for it, which is why passkeys resist the phishing that captures passwords and codes.

Presence against verification. In Chrome DevTools open WebAuthn, enable the virtual authenticator environment, and add a CTAP2 authenticator that supports resident keys and user verification. In $ISSUER/account/security, sign in again if asked and register it as a second passkey for Ava.

Why it matters: you now control the flags the authenticator signs, which lets you test the tenant's policy check in Break it.

Break it

In DevTools, clear Is user verified on the virtual authenticator. Sign out and sign in at $ISSUER/login with the virtual passkey. The tenant refuses it, although the signature is valid.

Why it matters: a touch alone is user presence, not verification. The policy requires verification, so the tenant must reject the response, exactly as the lesson describes.

Restore: in $ISSUER/account/security, sign in with Ava's real passkey and remove the virtual passkey. Removing a method also needs a sign-in from the last 10 minutes.

Check your work

Press Check my progress. The checks follow the registration, the passwordless sign-in, the refused unverified response and the removal.

Also confirm by hand:

Ava's ID token contained swk or hwk together with mfa.
btl-lab verify passed every check.

Cleanup

Keep Ava's real passkey; later labs use it. Remove the DevTools virtual authenticator.
If you turned on passkeys in Lab Mail only for step 5, set them back to Off there.
Ava now has a second-step method, so her next password sign-in asks for her passkey as a second step. That is expected.

Back to all labs

Create a tenant