Passkeys Explained: How Passwordless Sign-In Actually Works

What is a passkey?

A passkey is a sign-in credential built on the FIDO standards. Instead of a shared secret, it is a key pair: a private key that stays on your device (or in your encrypted password manager) and a public key that the website stores. You unlock it the same way you unlock your device, with a fingerprint, face scan, PIN or pattern.

Three properties make it different from a password:

• One passkey per service. Each passkey is created for a single site, so there is nothing to reuse across accounts.
• The server holds no secret. A breached database only exposes public keys, which cannot be used to sign in.
• It refuses to work on the wrong site. The browser and operating system enforce which site a passkey belongs to, so users do not have to spot look-alike domains themselves.

How passkeys work: the sign-in handshake

Passkeys on the web use the Web Authentication API (WebAuthn), which browsers expose to JavaScript. There are two ceremonies: registration, when the passkey is created, and authentication, when it is used.

1. Registration

1. The server generates a random challenge and sends it along with details about itself (the relying party) and the user.
2. The page calls navigator.credentials.create(). The device asks you to confirm with your screen lock.
3. Your authenticator generates a brand-new key pair and returns the public key, tagged with the site's identity.
4. The server checks the challenge and origin, then saves the public key against your account.

2. Authentication

1. The server issues a fresh challenge.
2. The page calls navigator.credentials.get(); you approve with your fingerprint or PIN.
3. The authenticator signs the challenge with the private key. The signed data also includes the page's origin.
4. The server verifies the signature with the stored public key and confirms the challenge and site match.

// Simplified browser-side flow (server endpoints are placeholders)
const opts = await fetch("/webauthn/login/options", { method: "POST" })
  .then(r => r.json());

const assertion = await navigator.credentials.get({
  publicKey: PublicKeyCredential.parseRequestOptionsFromJSON(opts),
});

await fetch("/webauthn/login/verify", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(assertion.toJSON()),
});

Synced vs. device-bound passkeys

Not all passkeys live in the same place. The FIDO Alliance describes two kinds, and the difference matters for both convenience and risk.

What about signing in on a computer that has none of your passkeys? Google's developer guidance describes a cross-device option: the laptop shows a QR code, you scan it with the phone that holds the passkey, Bluetooth confirms the two devices are physically near each other, and you approve on the phone. It works across operating systems and browsers.

Passkeys vs. passwords and one-time codes

The FIDO Alliance cites Verizon's finding that most hacking-related breaches involve stolen credentials, plus vendor-reported results such as Amazon seeing faster sign-ins and Google seeing higher sign-in success with passkeys than passwords. Those numbers come from interested parties, but the direction is consistent.

Adding passkeys to your website: a developer checklist

• Serve over HTTPS. WebAuthn only works in a secure context.
• Use a fresh, random challenge every time (at least 16 bytes), store it server-side for the session, and accept it once.
• Verify origin and relying-party ID on every registration and sign-in response.
• Use a maintained server library rather than hand-rolling CBOR parsing and signature checks.
• Offer autofill. Conditional mediation with autocomplete="username webauthn" lets passkeys appear in the username field next to saved passwords, which eases the transition.
• Use passkeys for reauthentication before sensitive actions instead of asking for the password again.
• Plan recovery. Let users register more than one passkey and keep a tested recovery path; treat it like any other disaster recovery runbook for your application.
• Keep your markup clean. Proper labels and form semantics help both autofill and assistive tech, as covered in our guide to semantic HTML fundamentals.

MDN also warns relying parties against maintaining allowlists of specific authenticator models; for most sites, accepting any standards-compliant authenticator is the better default.

Frequently asked questions