Passkeys 3: authentication ceremony #39

New Issue

2026-08-17T17:14:30-05:00

bermudalamb commented

2026-08-17 17:14:30 -05:00

Part of the Passkeys project. Parent: #36. Depends on registration.

Scope

A customer signs in using a registered passkey instead of their password.

POST /api/customers/passkeys/login/begin — issues authentication options and a challenge
POST /api/customers/passkeys/login/finish — verifies the assertion and establishes an rd_session exactly as password login does

Requirements

On success it must go through the same session creation as password login, so cookie flags, expiry, and logout behave identically. A second, subtly different session path is how auth bugs get in.
A disabled account (#33) must not be able to authenticate here. Enforcing it only on the password path would leave passkeys as a way around it.
Failures must not reveal whether an email has an account or has passkeys registered.
The signature counter is checked and updated per the policy set in the groundwork issue.

Decision

Discoverable credentials (usernameless — the browser offers accounts directly) or an email-first flow (customer types their email, then the passkey prompt appears). Usernameless is the better experience but changes what the login page looks like.

Part of the Passkeys project. Parent: #36. Depends on registration. ## Scope A customer signs in using a registered passkey instead of their password. - `POST /api/customers/passkeys/login/begin` — issues authentication options and a challenge - `POST /api/customers/passkeys/login/finish` — verifies the assertion and establishes an `rd_session` exactly as password login does ## Requirements - On success it must go through the same session creation as password login, so cookie flags, expiry, and logout behave identically. A second, subtly different session path is how auth bugs get in. - A **disabled account (#33) must not be able to authenticate here.** Enforcing it only on the password path would leave passkeys as a way around it. - Failures must not reveal whether an email has an account or has passkeys registered. - The signature counter is checked and updated per the policy set in the groundwork issue. ## Decision Discoverable credentials (usernameless — the browser offers accounts directly) or an email-first flow (customer types their email, then the passkey prompt appears). Usernameless is the better experience but changes what the login page looks like.

bermudalamb referenced this issue

2026-08-17 17:16:07 -05:00

Passkey (WebAuthn) login for customers #36

bermudalamb added this to the Passkey Implementation project 2026-08-17 17:21:30 -05:00

bermudalamb self-assigned this 2026-08-21 16:09:54 -05:00

bermudalamb referenced this issue from a commit

2026-09-09 13:48:13 -05:00

feat(passkeys): schema, dependency and per-environment Relying Party (#37)

bermudalamb referenced this issue

2026-09-09 13:48:33 -05:00

feat(passkeys): schema, dependency and per-environment Relying Party (#37) #330

bermudalamb referenced this issue from a commit