WebAuthn defines how a website can authenticate users with public-key credentials instead of passwords through a browser and an authenticator. A passkey is a credential experience built on this protocol: the site stores a public key for verification, while an authenticator uses the corresponding private key to sign. In practice, the private key may be managed by a device authenticator or a synchronization service, so it should not be described as always confined to one physical device.

1. What the site and authenticator do during registration

When an account registers a credential, the server provides a challenge and relying-party information to the browser. Based on user action and policy, the browser invokes an available authenticator, such as a platform authenticator or security key. The authenticator performs user-presence and, when configured, user-verification checks, then returns public-key information for the new credential. The server validates the response and stores the credential identifier and public key with the account.

The stored public key is used to verify a later sign-in signature. A registration challenge should be treated as single-use, and the server must check the ceremony context, including origin and relying-party ID. The fact that a browser and authenticator performed an API call does not remove the server's verification responsibility. Trust the registration only after checking the challenge, origin, credential data, and applicable policy.

2. Verifying an assertion at sign-in

For sign-in, the server issues a fresh challenge and the browser requests an assertion from an existing credential. The browser creates clientDataJSON containing the challenge and passes its SHA-256 hash to the authenticator. The authenticator signs the concatenation of authenticator data and that hash with the credential private key, so the signed bytes are not the challenge alone. The server verifies the signature with the stored public key and checks that the challenge is recent and belongs to the current session. A reused challenge, unexpected origin, or mismatched relying-party context must not be accepted as a successful login.

The credential ID helps locate the key associated with the authenticator. User presence and user verification are distinct concepts. Presence indicates participation in the ceremony; verification can indicate that the authenticator checked the user through a PIN, biometrics, or another configured method. A service should request and interpret the level required by its account-risk policy instead of treating these signals as interchangeable.

3. Passkey synchronization and account recovery

Depending on the platform, passkeys may be synchronized for use across multiple devices, while other credentials may be held by a separate authenticator such as a security key. The WebAuthn protocol defines the interaction between a site and an authenticator; it does not define one universal synchronization, backup, or account-recovery model for every provider. A product should provide a recovery plan, a way to register a new device, and a way to revoke credentials associated with a lost device.

Public-key authentication can reduce password reuse, but it does not remove risks in account recovery or device ecosystems. Decide in advance what evidence is required to recover an account after all authenticators are lost and how existing credentials are retired after recovery. Availability and passkey portability depend on platform and provider settings, so avoid promising either that losing one device makes sign-in impossible or that every device will recover automatically.

4. Security and operational checks before deployment

The W3C specification defines the browser-mediated creation and authentication ceremonies and the meaning of their verification data. MDN's Web Authentication guide gives developers a practical overview of public-key registration and authentication. Neither source is a substitute for a service's server-side verification logic. The service must check challenge generation, lifetime and single-use behavior, origin and RP ID, credential status, and the requested user-verification policy.

Before deployment, test registration and sign-in over HTTPS from allowed origins, along with fallback behavior for unsupported browsers and account recovery. Avoid storing complete sensitive authentication responses or secret material in logs, and distinguish verification failures from user cancellation or unsupported features. Passkeys make passwordless authentication possible; they do not automatically solve recovery, session management, or access control.

Sources