How Passkeys Work Under the Hood: WebAuthn, FIDO2, and Public-Key Cryptography

Quick Answer: When you register a passkey, your device generates a unique public/private cryptographic key pair using the WebAuthn standard. The public key is sent to the website server, while the private key remains locked inside your device's Secure Enclave, TPM chip, or password manager vault. During login, the server sends a single-use mathematical challenge (nonce) which your device signs locally upon biometric confirmation. Because the private key never travels across the network, passkeys cannot be stolen via phishing, keyloggers, or database dumps.

The Three Architectural Pillars: FIDO Alliance, W3C WebAuthn, and CTAP2

To understand the engineering behind passkeys, it is essential to distinguish between the three technical standards that enable passwordless authentication:

1. FIDO2 (Fast ID Online 2): The overarching industry project created by the FIDO Alliance (including Apple, Google, Microsoft, and Yubico) to standardize phishing-resistant authentication worldwide.
2. W3C WebAuthn (Web Authentication API): The official JavaScript browser standard (navigator.credentials.create() and navigator.credentials.get()) allowing web applications to communicate securely with authentication hardware.
3. CTAP2 (Client-to-Authenticator Protocol): The transport layer that allows your web browser or operating system to communicate with external hardware authenticators via USB, NFC, Bluetooth Low Energy (BLE), or internal system buses.

Phase 1: Passkey Registration (How Keys Are Generated)

When you click "Create a Passkey" or "Turn On Passkeys" in an online account, the following cryptographic handshake occurs in milliseconds:

1. Server Challenge: The Relying Party (website server) creates an options object containing a cryptographically random 32-byte challenge (nonce), the Relying Party ID (rp.id = "github.com"), user metadata, and supported cryptographic algorithms (such as ES256 / ECDSA over curve P-256 or Ed25519).
2. Browser WebAuthn Invocation: The browser calls navigator.credentials.create({ publicKey: options }). The operating system prompts the user for local biometric authorization (Touch ID, Face ID, or Windows Hello PIN).
3. Key Pair Generation: Upon user confirmation, the hardware authenticator (Apple Secure Enclave, Android Titan M2, or a hardware YubiKey) generates a fresh, unique asymmetric key pair:
   • Private Key: Bound permanently to the authenticator storage. It is mathematically impossible to export or read this key via software APIs.
   • Public Key: Encoded into a standard W3C Attestation Object along with a unique Credential ID.
4. Server Storage: The browser sends the public key, Credential ID, and signature counter to the server. The server stores this public key in the user's database row. The public key is completely harmless if leaked; it can only verify signatures, not forge them.

Phase 2: Passkey Authentication (How You Log In)

When you return to the website to sign in, no password ever passes through the login form:

1. Authentication Request: The server generates a fresh 32-byte challenge nonce and issues navigator.credentials.get({ publicKey: options }).
2. Hardware Signature: The browser matches the server's Relying Party ID to the stored Credential ID. After the user provides Face ID or fingerprint consent, the device's private key cryptographically signs a payload containing:
   • The server's challenge nonce
   • The authentic browser origin (e.g., https://github.com)
   • The authenticator data flags (User Present: UP=1, User Verified: UV=1)
3. Zero-Trust Verification: The server receives the cryptographic signature and verifies it using the public key stored on file. If the mathematical signature matches, the server issues an authenticated HTTP session cookie.

The Cryptographic Magic: Why Origin Binding Destroys Phishing Proxies

In traditional phishing, attackers deploy Adversary-in-the-Middle (AiTM) reverse proxies like Evilginx to intercept login forms, session cookies, and SMS/TOTP codes in real time.

Passkeys are 100% immune to this attack by mathematical design:

When you visit a fake lookalike site (such as github-security-login.com), your browser automatically supplies github-security-login.com as the origin payload to the WebAuthn API. Because your private key is cryptographically bound to github.com, your authenticator refuses to sign the payload. Even if an attacker tricked you into tapping Face ID, the signature would contain the fake origin, which the authentic GitHub server would immediately reject as invalid.

Synced Passkeys vs. Device-Bound Hardware Keys

For accounts and legacy portals that have not yet migrated to FIDO2 WebAuthn, always generate cryptographically unique credentials with our Free Password Generator or generate memorable high-entropy passphrases using our Passphrase Generator.