Security keys, passkeys, and biometrics
Signing in with your device
Alex chooses a passkey on Cedar Inc.'s sign-in page. A device asks for a fingerprint or PIN, then signs Alex in without an account password. The fingerprint or PIN unlocks an authenticator locally. Cedar Inc. receives a cryptographic response instead.
That response comes from a public-key credential. Its private key produces a signature, and its public key lets Cedar Inc. check that signature. The service can know the public key without being able to sign in as Alex; it does not receive the private key.
WebAuthn lets a website ask a browser to use this kind of credential. A separate security key can connect by USB or NFC, while another authenticator may be built into a phone or computer. A passkey is a FIDO credential used for passwordless sign-in. It can be held by a security key or a device's credential provider.
Registering a key
Before Alex can sign in this way, Cedar Inc. must register the credential to Alex's account. Cedar Inc. is the relying party, the service that will rely on the result. The authenticator creates a key pair, and the service stores the public key and a credential identifier after validating the registration response.
The credential is tied to the relying party's domain, such as login.cedar.example. The browser also knows the page's origin, which includes its scheme, host, and port. During registration and sign-in, these values help keep a credential for Cedar Inc. from being used by an unrelated website.
Registering a new key changes who can enter Alex's account. If someone briefly gets access to Alex's session, they should not be able to add their own key without a suitable fresh check. Cedar Inc. must authorize the change and notify Alex afterward.
Answering a challenge
At sign-in, Cedar Inc. sends a fresh, unpredictable challenge. The browser passes the request to an authenticator for the right domain. After Alex completes the required local check, the authenticator signs authentication data and a hash of browser-provided data that includes the challenge and origin.
Cedar Inc. checks that the response belongs to the challenge it sent, came from an allowed origin, is bound to its relying-party ID, and carries a valid signature from Alex's registered key. It also checks whether the authenticator performed any user verification the policy required. A maintained WebAuthn verifier handles these protocol checks.
A lookalike site has a different origin and cannot simply request Cedar Inc.'s credential through the browser. That website binding is why a passkey sign-in resists the kind of phishing that can capture a password or a code typed into a fake page.
Presence and verification
Touching a security key shows user presence: someone is participating in the sign-in. It does not tell Cedar Inc. whether that person is Alex. A local PIN or biometric check provides user verification through the authenticator.
Suppose Cedar Inc.'s policy requires user verification, but the key returns a valid signature after a touch alone. The signature is genuine, yet the required local check did not happen. Cedar Inc. must reject that sign-in.
In the fingerprint example, the comparison happens on Alex's device. Cedar Inc. checks the authenticator's signed indication that user verification occurred; it does not receive a fingerprint image or PIN.
Where keys live
A device-bound credential remains in one authenticator. A synced passkey can become available on several devices through a credential provider's protected sync system. Sync does not send the private key to Cedar Inc.; the service continues to hold the registered public key.
Sync can make replacing a phone easier, but access then depends in part on the provider's account security and recovery. A device-bound key needs another plan for loss or damage, such as a separately enrolled backup. Alex can also use a phone to sign in on another computer without storing the credential on that computer.