How FIDO Authentication Works

An explanation of how FIDO2 / WebAuthn actually works — what happens on your device, what happens on the server, and why the design is phishing-resistant by construction. Written for people who want to understand the system, not get lost in the spec.

The short version: FIDO replaces passwords with a public-key signature. The signature is generated inside a hardware authenticator (a smart card, a USB key, a phone’s secure element) using a private key that never leaves the device. The server verifies the signature against the public key it stored at registration. That’s it.

The long version explains why each design decision is there.

The three actors

1. You. The person signing in.
2. Your authenticator. The hardware that holds the private key. Could be a security key, a smart card, a phone’s secure enclave, or a TPM in your laptop.
3. The relying party (RP). The website or service you’re signing in to.

FIDO’s job is to let the RP verify that you, with your specific authenticator, are present, without anyone else being able to impersonate either side.

Registration: one-time

When you sign up for a service with FIDO, the following happens:

1. The RP generates a random challenge and sends it to your browser, along with the RP’s origin (e.g. example.com) and your user ID.
2. Your browser passes the challenge + origin to your authenticator.
3. Your authenticator generates a brand-new keypair — a private key that stays inside the authenticator, and a public key it’s about to share.
4. Your authenticator returns the public key + a signature over (challenge, origin, public key) using its attestation key — a separate identity that says "this keypair was generated on certified hardware".
5. The RP verifies the attestation signature and stores the public key + a credential ID under your user account.

You’ve now registered. The RP has your public key. Nobody else has your private key — not even the RP.

Authentication: every login

When you come back to sign in:

1. The RP generates another fresh challenge and sends it to your browser, with the credential ID it stored at registration.
2. Your browser passes the challenge + origin + credential ID to your authenticator.
3. Your authenticator looks up the matching private key, requires you to prove you’re present (PIN, biometric, button press), and signs (challenge, origin) with the private key.
4. The signature is returned to the RP.
5. The RP verifies the signature using the public key it stored at registration. Match ? signed in.

Origin binding (the key insight)

The signature is over the origin (example.com), not just the challenge. So:

• You visit a phishing site at examp1e.com.
• The phishing site presents a login page that looks identical.
• The browser receives an authentication request and asks your authenticator to sign with the origin examp1e.com.
• Your authenticator looks up "which credential is registered for examp1e.com?" and finds nothing — your real credential is registered for example.com.
• Authentication silently fails.

The user doesn’t need to spot the typosquatted domain. The browser doesn’t need to detect it. The authenticator simply doesn’t have a credential bound to the wrong origin. That is why FIDO is phishing-resistant by construction.

User verification (UV)

Before signing, the authenticator confirms you’re present. Three flavours:

• User presence — a touch on the key’s capacitive button. Confirms someone is there.
• User verification — a PIN or biometric. Confirms this specific user is there.
• None — rare; only acceptable for silent re-authentication of an already-verified session.

An enterprise deployment usually requires UV (PIN or biometric) for every login. Consumer flows often accept UP (touch only) on the assumption that the user’s holding the device.

Attestation — the "what hardware is this?" question

At registration, the authenticator can include an attestation statement — a signed declaration from the manufacturer that this is genuinely a model XYZ authenticator. The RP can verify the attestation against the FIDO Metadata Service (MDS) and decide whether to accept registrations from this device class.

For an enterprise rollout, attestation lets you enforce "only AmbiSecure-issued credentials register against employee accounts". Without it, an employee could register a personal key against their corporate account, with no way for the RP to tell.

For the byte-level mechanics, see Understanding WebAuthn Attestation Objects.

Passkeys, security keys, smart cards — same protocol, different storage

FIDO2 / WebAuthn is the protocol. The credential can live in many places:

• A USB security key: device-bound; lose the key, lose the credential.
• A smart card: device-bound; can also carry badge artwork, transit applet, etc.
• A phone or laptop’s secure enclave: platform authenticator; usually device-bound.
• A passkey synced through a cloud account (iCloud Keychain, Google Password Manager, 1Password, etc.): account-bound; recoverable on a new device.

The protocol behaviour is the same. The deployment tradeoffs are different. See Smart Cards vs FIDO Tokens vs Passkeys for the matrix.

What FIDO replaces

A quick note on CTAP2

The browser doesn’t talk to your USB key directly. It talks via CTAP2 (Client to Authenticator Protocol). CTAP2 sits between WebAuthn (browser ? RP) and the authenticator hardware. You usually don’t need to think about it — the browser and the platform handle it — but when you’re debugging a registration that doesn’t work, "CTAP2 error" in the console is what you’ll see.

See also

• Where Your AmbiSecure FIDO Key Works
• Implementing FIDO2 — A Complete Developer Guide
• Understanding WebAuthn Attestation Objects
• Passkeys vs Traditional MFA
• Platform vs Roaming Authenticators
• Smart Cards vs FIDO Tokens vs Passkeys
• Technology: FIDO
• Technology: WebAuthn
• Technology: CTAP2