IDENTITY SECURITY · LAB

Compare a relayable sign-in with a passkey sign-in

Sign Ava in twice, once with a password and authenticator code and once with a passkey, compare what each proves, and see the browser refuse to offer her passkey on another site.

Partly readyUses both lab tenants

The lesson

Phishing and relayed sign-insPractices Why codes and approvals pass straight through, Credentials that check where they are used, Limiting the damage

Builds on: Why attackers go after identity.

New to the labs? Start with the lab toolkit and the shared cast and names every lab uses.

Partly ready. Most of this lab runs today. Steps that wait on platform features are marked, and Missing infrastructure says what they need.

G37 Security context in Audit (network, device, session, method; subject on failed sign-ins) and user "this wasn't me" reporting
G66 Second lab tenant for every learner: additional tenants need a paid subscription or a BTL grant, so labs that use Lab Mail cannot be completed by an ordinary learner yet

Needs a second tenant. This lab also uses Lab Mail, a second tenant. Additional tenants currently need a paid subscription or a BTL grant, so you may not be able to do the Lab Mail steps yet (gap G66).

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.

Ava signs in with her password
Recorded as account.sign_in succeeded about [email protected].
Ava completes the authenticator code step
Recorded as account.second_step succeeded (second_step_completed) about [email protected].
Ava signs in again with her passkey
Recorded as account.sign_in succeeded about [email protected].
The Token Decoder receives a code for the passkey sign-in
Recorded as oauth.authorize succeeded (code_issued) about [email protected].

Setup

Press Start on this page.
Confirm at $ISSUER/account/security, signed in as Ava, that she has a password, an authenticator app and a passkey. If not, finish the first lab of this track.
In the Lab Mail tenant, open Authentication and set Passkey or security key to Optional with Passwordless on. Lab Mail has no account for Ava, and it does not need one.

Walkthrough

Open $ISSUER/token-decoder, tick the option that asks for a fresh sign-in (prompt=login), keep the scopes openid profile email, and start the sign-in. Sign in as Ava with her password, then choose the authenticator app and type the current code.

Why it matters: a password and a six-digit code are values a person types. Nothing in either one names the site that asked for it, which is why the lesson's relay can forward both while they are still valid.

In the Token Decoder, read the ID token's amr. It lists pwd and otp, and mfa because two kinds of factor were used. Note the authorization response's iss and that the Decoder used PKCE.

Why it matters: iss and PKCE bind the response to your issuer and to the client that started the flow. They cannot tell where the person typed the code. In the lesson's relay, every step reached the real provider and passed its checks.

Run the Decoder again with a fresh sign-in, and this time choose the passkey. Read amr again: swk for a synced passkey or hwk for one kept on a single device, plus mfa because your device verified you with a PIN or biometric.

Why it matters: the browser offered the passkey only because the page's origin matched the site the passkey was registered for. You did not need to read the address bar; the browser had already compared it.

Look closely at the browser's passkey prompt. It names your tenant's host, tenant-<your-tenant-id>.beyondthelogin.dev.

Why it matters: phishing resistance moves the address check from the person to software. The signed response also includes the page's origin, so a response made on another site would fail the tenant's check.

In Audit, source Protocol activity, open the two account.sign_in events and the account.second_step event between them. Read what each record holds: operation, outcome, reason, subject and request ID. Write down what it does not hold: the network address, the device and the sign-in method.

Why it matters: the lesson's relay left traces (a hosting-provider address, a session that changed networks minutes later). Detection depends on that context, and your tenant does not record it yet. See Missing infrastructure.

Break it

Open $ISSUER2/login, the Lab Mail sign-in page, and choose to sign in with a passkey. Your browser has no passkey to offer for this site, even though Ava's passkey is on the same device. If you saved Ava's password in a password manager, it is not suggested here either.

Why it matters: this is the property that defeats a look-alike page. A different host is a different site, so the passkey stays silent however convincing the page looks. A password manager hesitates the same way, but you could still copy and paste the password; a passkey has no such override.

Check your work

Check my progress confirms the password sign-in, the code step, the passkey sign-in and the authorization code issued to the Token Decoder.
The two ID tokens' amr values differ: pwd and otp for the first, swk or hwk for the second.
Your notes list which fields the sign-in records lack.

Cleanup

In Lab Mail, you can set the passkey method back to Off if you do not use it elsewhere.

Missing infrastructure

G37: sign-in records hold no source network, device or sign-in method, so the relay traces the lesson describes (a sign-in from a hosting provider, a session that moves networks) cannot be observed, and users have no way to report "this wasn't me." Once it exists, the lab will sign Ava in from two networks, read the recorded context on each account.sign_in event, and file a report as Ava.
G66 Second lab tenant: this lab uses Lab Mail, a second tenant. Additional tenants currently need a paid subscription or a BTL grant, so an ordinary learner can do only the Lab Photos steps until every learner can have a second lab tenant.

Back to all labs

Create a tenant