Passkeys and WebAuthn: Passwordless Auth, Explained

The problem passwords can't solve

Every password system shares one fatal flaw: there is a secret the user knows and the server stores. That single fact is the root of phishing, credential stuffing, database breaches, and password reuse. You can bolt on a TOTP app to slow attackers down, but a convincing fake login page can capture the password *and* the six-digit code in real time and replay both before they expire.

Passkeys remove the shared secret entirely. Instead of something you know, authentication becomes something your device *holds and proves*, a private key that never leaves the device and is cryptographically bound to the exact site you registered on. This article explains FIDO2 and WebAuthn from first principles, walks the registration and authentication ceremonies, and shows the actual code. If you're shaky on the difference between proving who you are and what you're allowed to do, read authentication vs authorization first.

What a passkey actually is

A passkey is a public/private key pair created on your device, where the private key never leaves and the public key is handed to the website, so the only way to log in is to prove possession of a key that nothing on the server side can leak.

WebAuthn is the browser API (a W3C standard) that lets a web page ask the device to create and use these keys. FIDO2 is the umbrella term covering WebAuthn plus CTAP, the protocol that lets a browser talk to an external security key over USB, NFC, or Bluetooth. The website that wants to authenticate you is called the relying party (RP).

Platform vs roaming authenticators

An authenticator is the thing that holds the private key and performs the crypto. There are two flavours. A platform authenticator is built into the device, Face ID / Touch ID on Apple, the fingerprint sensor and screen lock on Android and Windows Hello. A roaming (cross-platform) authenticator is a separate physical device like a YubiKey that you plug in or tap. Platform authenticators give you the smooth 'just look at your phone' experience; roaming keys are portable across machines and favored for high-security and shared-device scenarios.

The registration ceremony, drawn out

Registration (the spec calls it attestation) is how a brand-new passkey gets created and its public key handed to your server. The browser sits in the middle, brokering between your server and the authenticator, it is the only party that gets to confirm which origin is actually asking, which is what makes the whole thing phishing-resistant.

1. 1

   Server generates a challenge

   Your backend creates a random, single-use challenge plus registration options (the RP id, user handle, and which authenticator types are allowed) and sends them to the page.

2. 2

   Browser calls the authenticator

   The page passes those options to navigator.credentials.create(). The browser stamps in the real origin it is running on, the page can't fake this.

3. 3

   User proves presence

   The authenticator asks for a biometric or PIN (user verification) so a key isn't minted silently.

4. 4

   Key pair is minted

   The authenticator generates a new private/public key pair bound to this RP id. The private key stays locked in hardware forever.

5. 5

   Public key returns

   The browser sends back the public key, a credential id, and signed client data (including the origin and challenge), the attestation object.

6. 6

   Server verifies and stores

   The backend checks the challenge matches, the origin and RP id are correct, then stores the public key + credential id against the user. No secret is ever stored.

Why passkeys beat passwords + TOTP

The headline win is phishing resistance, and it isn't a policy or a heuristic, it's structural. The signature an authenticator produces is bound to the origin the browser reports. A passkey created for your-bank.com simply will not produce a valid signature for your-bank.evil.com, because the browser refuses to use it there. There is no code the user could be tricked into pasting.

Notice the third row: even a full database dump leaks nothing useful, because a public key can verify signatures but cannot create them. Compare that to a password breach, where every hashed secret is now a cracking target, or a TOTP seed leak, which lets an attacker generate valid codes forever. For the broader picture of where login state lives after authentication, see authentication and sessions in backends.

Wiring it up: client and server

Here's the authentication (assertion) ceremony in code. The flow mirrors registration: server issues a challenge, the browser asks the authenticator to sign it, the server verifies the signature against the stored public key. We'll use the @simplewebauthn libraries, which handle the fiddly byte encoding.

// 1. REGISTRATION, ask the device to create a passkey
import { startRegistration } from "@simplewebauthn/browser";

async function registerPasskey() {
  // Server returns challenge + options (PublicKeyCredentialCreationOptions)
  const options = await fetch("/api/register/start").then((r) => r.json());

  // Browser + authenticator do the work; user is prompted for biometric.
  // Internally this calls navigator.credentials.create({ publicKey: options }).
  const attestation = await startRegistration({ optionsJSON: options });

  // Send the attestation back for the server to verify + store.
  await fetch("/api/register/finish", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(attestation),
  });
}

// 2. AUTHENTICATION, prove you hold an existing passkey
import { startAuthentication } from "@simplewebauthn/browser";

async function loginWithPasskey() {
  // Server returns a fresh single-use challenge.
  const options = await fetch("/api/login/start").then((r) => r.json());

  // Wraps navigator.credentials.get({ publicKey: options }).
  // The authenticator signs the challenge with the private key.
  const assertion = await startAuthentication({ optionsJSON: options });

  // Server verifies the signature against the stored public key.
  const res = await fetch("/api/login/finish", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(assertion),
  });
  return res.ok; // session cookie set on success
}

// 3. SERVER, verify the assertion (@simplewebauthn/server)
import {
  generateAuthenticationOptions,
  verifyAuthenticationResponse,
} from "@simplewebauthn/server";

const rpID = "example.com";
const origin = "https://example.com";

// START: issue a challenge, remember it server-side (in the session).
export async function loginStart(session: Session) {
  const options = await generateAuthenticationOptions({ rpID });
  session.challenge = options.challenge; // single-use, expires fast
  return options;
}

// FINISH: confirm the signature came from the stored public key.
export async function loginFinish(session: Session, body: AuthResponse) {
  const credential = await db.getCredentialById(body.id);

  const verification = await verifyAuthenticationResponse({
    response: body,
    expectedChallenge: session.challenge,
    expectedOrigin: origin,
    expectedRPID: rpID,
    credential, // { id, publicKey, counter }
  });

  if (!verification.verified) throw new Error("Bad assertion");

  // Persist the new signature counter to detect cloned authenticators.
  await db.updateCounter(body.id, verification.authenticationInfo.newCounter);
  return startSession(credential.userId);
}

Syncing: how passkeys survive a lost phone

The obvious objection: 'if the private key never leaves my device, what happens when I drop my phone in a lake?' The answer is synced passkeys. Modern platform authenticators back the private key up, encrypted end-to-end, to the platform's credential cloud: iCloud Keychain on Apple, Google Password Manager on Android and Chrome, and similar for Microsoft and third-party managers like 1Password.

• Synced passkeys roam across all your devices signed into the same account. Buy a new phone, sign into iCloud, and your passkeys are there. This is the default for consumer apps.
• Device-bound passkeys never leave the hardware (a YubiKey, or platform keys with sync disabled). More secure, no recovery if lost, used for high-assurance enterprise and admin accounts.
• The sync provider only ever holds encrypted key material it cannot read; the keys are decrypted on-device behind your device unlock.

For your server, the sync model is mostly invisible, you still just store public keys. But it's why you should let users register multiple passkeys and keep a recovery path: a user might add a phone passkey and a hardware key for redundancy.

Common mistakes that cost hours

1. Mismatched RP id. The RP id must be the site's registrable domain (example.com), not a full URL and not a subdomain you serve from. Get this wrong and create()/get() throw a cryptic SecurityError.
2. Reusing or not storing the challenge. Each ceremony needs a fresh, single-use challenge held server-side and compared on finish. Skipping it opens you to replay attacks, the whole point of the challenge.
3. Trusting client-sent origin or challenge. Always verify expectedOrigin and expectedChallenge on the server. Never let the client tell you what they should be.
4. Ignoring the signature counter. The counter helps detect cloned authenticators. Persist newCounter after every login; a counter that goes backwards is a red flag.
5. Storing only one passkey per user. With no second credential and no recovery flow, a lost device locks the user out. Support multiple credentials.
6. Testing over HTTP on a real domain. WebAuthn only runs on secure contexts; localhost works for dev, but staging on plain HTTP will silently fail.

Takeaways

Where to go next

Passkeys answer 'who are you'. The rest of an auth system decides what happens next, sessions, tokens, and permissions. These build directly on what you just learned.

• Authentication vs authorization, proving identity vs deciding what that identity may do.
• Authentication and sessions in backends, what to issue once a passkey login succeeds.
• HTTPS, TLS, and encryption basics, the secure channel WebAuthn depends on.