Passkeys and WebAuthn (FIDO2): How Passwordless Sign-In Works

Passkeys and WebAuthn are changing how people sign in to websites and apps: instead of typing a reusable secret, a person approves a cryptographic challenge with a device or credential manager. This explainer is for developers, security teams, and anyone trying to understand what “passwordless” actually means, where FIDO2 fits, and what a service must do to adopt passkeys safely.

What Are Passkeys and WebAuthn?

A passkey is a public-key credential used to sign in to an account. During enrollment, an authenticator creates a key pair associated with the service. The service stores the public key; the private key stays under the control of the authenticator or credential manager. At sign-in, the service sends a fresh challenge, and the authenticator signs it after the user approves.

WebAuthn (Web Authentication) is the browser-facing web standard for creating and using these credentials. The Web Authentication API documentation describes how a web application asks a browser to create or use a public-key credential. The browser mediates communication with an authenticator, such as a phone, computer, security key, or platform credential manager.

FIDO2 is the broader set of standards and protocols behind passwordless authentication. In a web flow, WebAuthn defines the interaction between the website and browser, while CTAP lets a browser or operating system communicate with an external authenticator. “Passkey” is the user-facing term commonly used for a FIDO credential that can be used across devices or synced by a credential provider. Not every WebAuthn credential is synced: some are bound to one authenticator.

The Problem Passkeys Solve

Passwords are shared secrets. A site must check a password supplied by the user, and people often reuse passwords across services. A breach can expose password hashes for offline guessing, while phishing pages can trick people into entering credentials and one-time codes. Adding another factor can reduce risk, but it does not necessarily prevent a user from approving a fraudulent sign-in on a convincing fake site.

Passkeys replace the reusable sign-in secret with a challenge-response exchange. The service never receives the private key, and a passkey is scoped to a relying party (the site or app that registered it). The browser checks the web origin as part of the operation, so a credential registered for one domain cannot normally be used by a look-alike phishing domain. This origin binding is why correctly implemented passkeys are considered phishing-resistant.

That protection is not a guarantee against every account attack. A compromised device, malicious software, weak account recovery, unsafe enrollment, or stolen authenticated session can still put an account at risk. Passkeys change the credential and its verification path; they do not replace sound application security.

How Passkey Sign-In Works

Registration and authentication use different WebAuthn operations. In both, the server creates a random, short-lived challenge and verifies the response. The browser and authenticator bind the response to the requesting site and requested operation.

Registration: After the user is signed in or otherwise verified, the server returns creation options containing a challenge, the relying party, a user handle, and acceptable credential algorithms. The browser asks an authenticator to create a credential. The authenticator may ask for a biometric, device PIN, or physical key touch as user verification or presence. The browser returns an attestation response; the server checks the challenge, origin, relying-party ID, and response before saving the credential’s public key and identifier.

Authentication: The server returns a new challenge and allowed credential IDs, if the user is already known. The browser requests an assertion from an authenticator. The authenticator signs data that includes the challenge and relying-party context. The server verifies the signature with the stored public key, checks that the challenge is fresh and matches the outstanding request, validates the origin and relying-party ID, and applies the application’s user-verification policy. Only then should it establish a session.

The W3C Web Authentication specification defines the browser API and the credential ceremony. In production, applications should use a maintained WebAuthn server library rather than implementing CBOR parsing, signature verification, or challenge validation themselves.

Key Components and Variants

• Relying party (RP): The website or app that owns the account. It sets its RP ID, issues challenges, verifies responses, and stores public credential data. For a website, the RP ID is a domain and must match the site’s origin rules.
• Browser or client: Calls WebAuthn, checks secure-context and policy requirements, and mediates the request. WebAuthn is generally available only in secure contexts such as HTTPS, with localhost commonly treated specially for development.
• Authenticator: Creates and uses the credential. It may be built into a device, such as a phone or laptop, or be a roaming hardware security key.
• Credential manager: Stores, unlocks, or synchronizes eligible passkeys across a user’s devices. The FIDO Alliance passkey overview explains the passkey model and how users may access credentials from more than one device.
• User verification and presence: A biometric or device PIN can locally unlock the authenticator; a touch may show that the user is present. A website receives a cryptographic result and verification flags, not the user’s fingerprint or face data.

Passkeys can be device-bound, usable only through a particular authenticator, or synced, backed up and made available on other devices through a credential provider. Sync improves convenience and recovery but adds a dependency on that provider’s account security and recovery process. Organizations with stricter hardware-control requirements may choose device-bound credentials and manage replacement keys separately.

Real-World Uses

Consumer websites use passkeys to simplify account sign-in while reducing password reuse and phishing exposure. Enterprise identity systems can offer them as a primary sign-in method or as a phishing-resistant factor for workforce accounts. Financial services and other high-risk applications may use passkeys for sign-in and step-up approval, while still applying transaction limits, risk checks, and recovery controls.

Passkeys are also useful on mobile devices, where the operating system can present a familiar biometric or PIN prompt without exposing biometric material to the app or website. They are not themselves an OAuth or OpenID Connect replacement: passkeys authenticate a user to an application, while protocols such as OAuth 2.0 and OpenID Connect handle delegated authorization and federated identity.

Getting Started: A Web Integration

A web implementation needs both a client and a server. The server creates registration and authentication options, associates the ceremony with the correct account, and verifies every response. A browser helper library can handle WebAuthn’s binary data conversion; for example, install @simplewebauthn/browser with npm:

npm install @simplewebauthn/browser

The following browser-side example assumes the application’s server exposes options and verification endpoints. Its server must use a WebAuthn implementation to generate options and validate the response; these endpoints are application-specific.

import {
  startAuthentication,
  startRegistration,
} from '@simplewebauthn/browser';

async function postJSON(url, body) {
  const response = await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(body ?? {}),
  });

  if (!response.ok) {
    throw new Error(`${url} failed with HTTP ${response.status}`);
  }

  return response.json();
}

export async function registerPasskey() {
  const optionsJSON = await postJSON('/api/passkeys/register/options');
  const registration = await startRegistration({ optionsJSON });
  return postJSON('/api/passkeys/register/verify', registration);
}

export async function signInWithPasskey() {
  const optionsJSON = await postJSON('/api/passkeys/authenticate/options');
  const authentication = await startAuthentication({ optionsJSON });
  return postJSON('/api/passkeys/authenticate/verify', authentication);
}

On the server, generate unpredictable one-time challenges, bind each challenge to the pending user and ceremony, and expire it after use or a short timeout. Verification must compare the expected origin and RP ID, check the challenge, verify the cryptographic response, and enforce the intended user-verification policy. Store each credential’s ID and public key against the account, and handle authenticator metadata and signature-counter behavior through a maintained server library.

To verify an implementation, test registration and sign-in on supported browsers and authenticators, reject a challenge replay, and confirm that a credential cannot authenticate from a different origin. Also test cancellation, unavailable authenticators, duplicate enrollment, account recovery, and the behavior when a user replaces or loses a device. Keep a tested non-passkey recovery path; do not make account access depend on a credential users can permanently lose.

Common Misconceptions

• “A passkey is just a password stored in a password manager.” It is a public-key credential used in a challenge-response protocol. A credential manager may store or sync it, but the service verifies a signature rather than receiving a password.
• “Passkeys always use biometrics.” A biometric prompt is one local way to unlock an authenticator. A device PIN, security-key touch, or another supported verification method may be used instead.
• “Passkeys make account recovery unnecessary.” Users still lose devices, change platforms, or lose access to credential-provider accounts. Recovery, enrollment, session security, and support processes remain part of the threat model.

Related Articles

• Authentication Methods for Web Applications compares passkeys with other sign-in approaches.
• Biometric Authentication Technologies explains how biometric checks work and where they fit into authentication.
• OAuth 2.0 and OpenID Connect Implementation covers delegated access and federated identity.

Changelog

• 2026-09-27: Published the canonical explainer.

Last updated: 2026-09-27