Protocols and how-tos
Passkeys for developers: how WebAuthn sign-in works
How passkey registration and authentication work under WebAuthn, why they resist phishing, synced versus device-bound passkeys, and account recovery.
The short answer
A passkey is a FIDO credential — a public/private key pair created by the user's device or password manager for one website. Under the W3C WebAuthn standard, the site stores only the public key; at sign-in the device signs a server challenge, and the browser includes the site's origin in what is signed, so a look-alike phishing domain cannot obtain a usable signature.
Sources last reviewed .
Registration
- The server creates a random challenge and calls navigator.credentials.create() options with the relying party ID (your domain), user handle and accepted algorithms.
- The authenticator generates a key pair scoped to that relying party ID, after user verification (biometric or device PIN).
- The server verifies the attestation response — challenge, origin, RP ID hash — and stores the credential ID and public key against the user.
Authentication
The server issues a fresh challenge; navigator.credentials.get() asks the authenticator to sign it. The server verifies the signature with the stored public key, checks the origin and RP ID hash, and confirms the user-verification flag if your policy requires it. There is no shared secret to steal from the server and nothing reusable to type into a fake page.
Synced and device-bound
Synced passkeys are backed up and shared across a user's devices by their platform or password manager, which makes them recoverable and practical for consumers. Device-bound passkeys (for example on a security key) never leave the hardware, which some regulated environments require. WebAuthn's backup-eligibility and backup-state flags let a server tell them apart.
The hard part is recovery
Passkeys remove phishable passwords from sign-in, but the account is only as strong as its recovery path. If 'lost your passkey?' falls back to an emailed link, that link is now the weakest factor. Plan for multiple registered passkeys per user, and treat recovery as an authentication event with its own controls.
In Authreads
How this applies to Authreads
Passkeys are Available for end users on hosted login and through the API, where the tenant allows them, with recovery codes for lost devices. A relying party can require a passkey with acr_values=urn:authreads:acr:phr.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.