Back to Blog

How Passkeys Work: The Technical Architecture Behind Passwordless Authentication

Prateek SinghFebruary 18, 202610 min read
How Passkeys Work: The Technical Architecture Behind Passwordless Authentication

Passkeys are replacing passwords across the web. Under the hood, they use public-key cryptography, platform authenticators, and the WebAuthn spec. Here's how it all fits together.

The Problem Passkeys Solve

Passwords are the most exploited attack vector in cybersecurity. They get reused, phished, stuffed, sprayed, and leaked. MFA helps, but SMS codes get SIM-swapped, TOTP codes get phished in real-time, and push notifications get fatigue-approved. The fundamental issue is that passwords are shared secrets — the server and the user both know the same value.

Passkeys eliminate shared secrets entirely. Authentication uses public-key cryptography: the server stores only a public key, the private key never leaves the user's device, and each authentication creates a unique cryptographic signature that can't be replayed or phished.

The Protocol: WebAuthn + CTAP

Passkeys are built on two specifications:

  • WebAuthn (Web Authentication API) — the browser-side JavaScript API that websites use to create and verify credentials
  • CTAP2 (Client to Authenticator Protocol) — the protocol between the browser and the authenticator (biometric sensor, security key, or platform authenticator)

Registration (Creating a Passkey)

  1. The server generates a random challenge and sends it to the browser along with relying party information (your domain) and user details.
  2. The browser calls navigator.credentials.create() and passes the challenge to the platform authenticator.
  3. The authenticator prompts the user for biometric verification (Face ID, fingerprint, Windows Hello).
  4. Upon verification, the authenticator generates a new asymmetric key pair (typically ECDSA P-256 or Ed25519). The private key is stored securely on the device. The public key, along with a credential ID and attestation data, is returned to the browser.
  5. The browser relays this to the server, which stores the public key and credential ID associated with the user account.

Authentication (Using a Passkey)

  1. The server sends a random challenge to the browser.
  2. The browser calls navigator.credentials.get() and passes the challenge to the authenticator.
  3. The authenticator prompts for biometric verification, then signs the challenge (plus additional context: origin, TLS channel ID) with the private key.
  4. The browser sends the signature back to the server.
  5. The server verifies the signature against the stored public key. If valid, the user is authenticated.

Why Passkeys Are Phishing-Resistant

The critical security property is origin binding. When the authenticator signs the challenge, it includes the website's origin (e.g., https://bank.com) in the signed data. If an attacker creates a phishing site at https://bank-login.com, the authenticator will sign with the phishing site's origin. The real server will reject the signature because the origin doesn't match.

This means that even if a user clicks a phishing link and attempts to authenticate, the passkey authentication will fail. The user cannot accidentally give their credentials to the wrong site — the cryptographic protocol prevents it structurally.

Cross-Device Sync

Early FIDO2 security keys (YubiKeys, etc.) stored private keys on a single physical device. Lose the key, lose access. Passkeys solve this through platform-level synchronization:

  • Apple: Passkeys sync via iCloud Keychain across all Apple devices
  • Google: Passkeys sync via Google Password Manager across Android and Chrome
  • Microsoft: Passkeys sync via Microsoft Account across Windows devices

The private keys are end-to-end encrypted before sync — the cloud provider cannot access them. The sync mechanism uses the platform's secure enclave for key storage on each device.

Implementation for Developers

Adding passkey support to a web application requires:

  1. Server-side library for generating challenges and verifying assertions. Libraries like @simplewebauthn/server (Node.js) or py_webauthn (Python) handle the cryptographic verification.
  2. Client-side API calls using the WebAuthn browser API. The API is well-supported across modern browsers.
  3. Database schema to store credential IDs, public keys, and sign counters per user.
  4. Conditional UI — using navigator.credentials.get() with mediation: 'conditional' to auto-fill passkey prompts in username fields.

The Transition Period

We're in the awkward middle phase where passkeys coexist with passwords. Most sites offer passkeys as an optional upgrade. The path to a passwordless future requires passkey support to reach critical mass across services and platforms. We're not there yet, but the technical foundation is solid and the user experience — authenticate with a glance or a fingerprint — is dramatically better than typing passwords.

References & Citations

  • W3C (2023). "Web Authentication: An API for Accessing Public Key Credentials (Level 3)." W3C Recommendation.
  • FIDO Alliance (2024). "Passkeys Technical Specification." fidoalliance.org.
  • Apple (2025). "Supporting Passkeys." Apple Developer Documentation.
Share this article

Related Posts