FIDO2 and WebAuthn: The Standard

The Three Actors

Every WebAuthn authentication involves exactly three parties. Understanding their roles is essential before the protocol makes sense:

1. The Relying Party (RP): The website or service you are logging into (e.g., github.com). It is called a "relying party" because it relies on the authenticator to prove the user's identity. The RP has a backend server that stores public keys and issues challenges.
2. The Client: The web browser (Chrome, Safari, Firefox, Edge). The browser acts as a trusted intermediary — it enforces origin binding (more on this shortly) and communicates between the RP and the authenticator via the WebAuthn JavaScript API.
3. The Authenticator: The hardware device that performs the cryptographic operation and proves who you are. This can be a platform authenticator (built into the device — TouchID, FaceID, Windows Hello, Android fingerprint) or a roaming authenticator (a separate hardware key like a YubiKey connected via USB or NFC).

How It Works: Public Key Cryptography

Unlike a password (a shared secret both parties must know), WebAuthn uses Asymmetric Cryptography — a mathematical technique where two related keys are generated together: one public, one private. Data signed with the private key can be verified with the public key, but the public key cannot be used to reconstruct the private key.

Registration (one-time setup):

1. You visit github.com and click "Set up a Passkey."
2. The server generates a random challenge (a nonce — a number used once) and sends it to the browser along with configuration options.
3. The browser calls navigator.credentials.create(), which triggers the OS to prompt for biometric verification (your fingerprint or face).
4. After you authenticate locally, the device's Secure Enclave (Apple) or TPM (Trusted Platform Module, on Windows/Android) generates a new key pair specifically for github.com. The private key is generated inside the secure hardware and never leaves it — not even the OS can read it directly.
5. The device signs the challenge with the new private key and returns the public key plus the signed challenge to the browser.
6. The browser sends the public key to github.com's server, which stores it associated with your account.

Authentication (every subsequent login):

1. You visit github.com and click "Sign in with Passkey."
2. The server generates a new random challenge and sends it to the browser.
3. The browser calls navigator.credentials.get(), triggering the biometric prompt.
4. The device's secure hardware signs the challenge with the stored private key.
5. The browser sends the signed challenge back to the server.
6. The server verifies the signature using the stored public key. If valid, you are authenticated.

The critical security property: The private key never leaves the device's secure hardware. The server stores only the public key. Even if the server is completely compromised, the attacker gains nothing useful — a public key cannot be used to authenticate.

Origin Binding: The Phishing Killer

When the device generates a key pair during registration, the browser includes the origin (the exact domain, e.g., https://github.com) in the data that gets signed and stored. When you attempt to authenticate, the browser checks whether the current page's origin matches the origin the credential was registered for.

If you are on https://gíthub.com (with a Unicode 'í'), the browser finds no credential for that origin and refuses to proceed. The user cannot be tricked into authenticating to a phishing site — the browser enforces this check automatically, regardless of how convincing the fake site looks.

This is a structural guarantee, not a user-education problem. It is why WebAuthn is described as phishing-resistant rather than merely phishing-aware.