FIDO2 and WebAuthn: The Future of Authentication

FIDO2 is an open authentication standard that replaces passwords with public-key cryptography, and WebAuthn is the browser API that lets websites use it. Together they enable passwordless and phishing-resistant login backed by hardware security keys or the secure elements built into phones and laptops. Because the private key never leaves the device and every signature is bound to the site's real origin, FIDO2 defeats the phishing and replay attacks that undermine passwords and one-time codes.

The Building Blocks: WebAuthn and CTAP

FIDO2 is made of two specifications that work together.

• WebAuthn is a web standard that defines a JavaScript API browsers expose to websites, allowing a site (the relying party) to request creation and use of credentials.
• CTAP (Client to Authenticator Protocol) defines how the client device talks to an external authenticator, such as a USB, NFC, or Bluetooth security key.

The website that wants to authenticate a user is the relying party. The authenticator is the component that holds private keys and performs signing. It may be a platform authenticator built into the device, protected by a fingerprint or PIN, or a roaming authenticator like a removable security key used across many devices.

Public-Key Credentials Instead of Shared Secrets

The central idea is that authentication uses an asymmetric key pair rather than a secret both sides know. During registration the authenticator generates a fresh key pair that is unique to that account and that website:

• The private key stays inside the authenticator's secure hardware and is never exported.
• The public key is sent to the relying party and stored with the user's account.

This eliminates the shared-secret problem that plagues passwords and one-time codes. There is nothing on the server that an attacker can steal and replay, because a public key cannot be used to forge a signature. A breach of the relying party's database exposes only public keys, which are useless to an attacker.

Registration: Creating a Credential

Registration binds a new key pair to the user's account. The flow proceeds as follows:

1. The relying party sends a random challenge and its identifying information to the browser.
2. The browser calls the WebAuthn navigator.credentials.create() API, passing the relying party's origin.
3. The authenticator verifies user presence, often with a fingerprint, face, or PIN, then generates a key pair scoped to that relying party.
4. The authenticator returns the public key plus an attestation signature that can vouch for the authenticator's make and model.
5. The relying party stores the public key and a credential identifier against the account.

A key detail is that the authenticator records the relying party's identity with the credential. This binding is what makes the credential impossible to use on any other site.

Authentication: Proving Possession

When the user returns to log in, the relying party proves the user controls the matching private key without any secret crossing the network.

1. Relying party  ->  browser:        challenge, allowed credential IDs
2. Browser        ->  authenticator:  challenge + verified origin (rpId)
3. Authenticator:  checks user presence, signs (challenge + origin + counter)
4. Authenticator  ->  browser:        signature + authenticator data
5. Browser        ->  relying party:  assertion
6. Relying party:  verifies signature with the stored public key

The authenticator signs a data structure that includes the server challenge, the origin, and a signature counter. The relying party verifies the signature using the public key it stored during registration. Because the browser supplies the true origin and the authenticator refuses to sign for a mismatched relying party identifier, a phishing site at a lookalike domain simply cannot obtain a valid assertion.

Why FIDO2 Resists Phishing

The origin binding is the crux. A traditional one-time code, as used in multi-factor authentication, can be relayed by a proxy because the user types a secret that works anywhere. In FIDO2 there is no such secret: the signature only validates for the exact registered origin, and the private key never leaves the device, so a real-time phishing proxy has nothing to capture or replay.

Passkeys and the Passwordless Experience

Passkeys are FIDO2 credentials designed to be the sole factor, replacing passwords entirely. A passkey is a discoverable credential (sometimes called a resident credential) stored on the authenticator so the user does not even need to type a username; the authenticator presents matching accounts for the site.

Passkeys come in two broad flavors:

• Device-bound passkeys never leave a single authenticator, offering the highest assurance.
• Synced passkeys are backed up and shared across a user's devices through a platform provider's encrypted cloud, trading a little assurance for recovery and convenience.

The signature counter helps detect cloning: if a device-bound authenticator is duplicated, the counters on the two copies diverge, and the relying party can flag the anomaly. Synced passkeys typically forgo this counter because the credential intentionally exists on multiple devices.

Deployment Considerations

Adopting FIDO2 well involves more than turning on the API.

• Account recovery becomes the weak point. If losing a security key drops the user back to a password or SMS code, the phishing resistance is undermined. Register a backup authenticator during enrollment.
• Attestation policy should match your threat model. High-security environments may require specific certified authenticators; consumer services often skip attestation to reduce friction.
• Fallbacks matter. Offering a weaker factor alongside passkeys can reopen the attacks passkeys were meant to close, so restrict fallbacks for sensitive accounts.

For environments still reliant on shared secrets, pairing FIDO2 with certificate-based authentication and monitoring for credential stuffing rounds out a layered defense.

Key Takeaways

• FIDO2 combines the WebAuthn browser API and the CTAP authenticator protocol to enable passwordless login.
• Authentication uses a per-site key pair; the private key stays in hardware and only public keys reach the server.
• Signatures are bound to the real origin, which makes FIDO2 phishing-resistant against relay and lookalike-domain attacks.
• Passkeys extend FIDO2 to replace passwords entirely and may be device-bound or synced across devices.
• Plan recovery and backup authenticators carefully, since weak fallbacks can undo the security FIDO2 provides.