WebAuthn Explained: The FIDO2 Standard Behind Passkeys

Passkeys get the attention, but the standard doing the work underneath is WebAuthn, part of the FIDO2 project. If you build or operate authentication, understanding WebAuthn is what lets you reason about what is actually happening when a user taps a security key or confirms with a fingerprint. This guide covers the roles, the two ceremonies, attestation, and the properties that make the whole thing phishing-resistant.

FIDO2: two halves of one system

FIDO2 is a joint effort of the W3C and the FIDO Alliance, and it has two components that fit together.

WebAuthn is the W3C standard: a JavaScript API in the browser that a website calls to register and use public-key credentials. It defines the messages between the website's server and the browser.

CTAP, the Client to Authenticator Protocol, is the FIDO Alliance standard for the other link: how the browser talks to the authenticator, whether that is a roaming USB or NFC security key or a platform authenticator built into the laptop or phone.

So a full login spans two hops. Server to browser is WebAuthn. Browser to authenticator is CTAP. Together they let a website ask a device to prove possession of a private key without any shared secret ever crossing the network.

The three roles

Every WebAuthn flow has three participants, and keeping them straight makes everything else clear.

Role	WebAuthn term	What it does
The website	Relying party	Stores public keys, issues challenges, verifies responses
The browser	Client	Mediates between the site and the authenticator, enforces origin
The device or key	Authenticator	Generates and holds private keys, signs challenges

The authenticator is where the private key lives and never leaves. It comes in two shapes. A platform authenticator is built into a device, such as the secure hardware behind a laptop's fingerprint reader or a phone's face unlock. A roaming authenticator is a separate device, typically a USB, NFC, or Bluetooth security key you carry. The best hardware security keys are roaming authenticators.

The registration ceremony

Registration is how a user enrols a new credential with a site. WebAuthn calls it a ceremony because it is a defined sequence across all three roles.

1. The relying party generates a random challenge and sends it to the browser, along with information about the site and the user, by calling navigator.credentials.create().
2. The browser passes the request to the authenticator, including the origin it is running on.
3. The authenticator asks the user to consent, with a touch, biometric, or PIN (this is the user gesture, proof a human is present).
4. The authenticator generates a fresh key pair scoped to this relying party. It keeps the private key and returns the public key, a credential id, and an attestation object.
5. The browser forwards this to the relying party, which stores the public key and credential id against the user's account.

From that point the site holds a public key it can use to verify future logins, and the private key exists only inside the authenticator. Because the key pair is bound to the relying party's identifier and the origin, a credential created for one site cannot be used at another.

The authentication ceremony

Authentication reuses that credential to log the user in. It mirrors registration but proves possession rather than creating a key.

1. The relying party generates a new random challenge and sends it, listing which credential ids it will accept, by calling navigator.credentials.get().
2. The browser passes the challenge and origin to the authenticator.
3. The user performs the gesture to unlock the private key locally.
4. The authenticator signs a data structure that includes the challenge, the relying party id, a signature counter, and flags, then returns the signature.
5. The relying party verifies the signature against the stored public key and checks that the challenge, origin, and relying party id all match what it expects.

Two properties fall directly out of this. The fresh challenge each time makes the response impossible to replay, since last login's signature does not satisfy this login's challenge. And the origin and relying party id checks mean the signature is only valid for the real site, which is the root of phishing resistance. For the practical user view of this, see Passkeys Explained. For the signing primitive, see How Digital Signatures Work.

The signature counter

Each authenticator can maintain a signature counter that increments every time it produces an assertion. It returns the current value in each authentication response, and the relying party can store the last value it saw.

The point is clone detection. If a relying party sees a counter that went backward or failed to advance in a way that suggests two copies of the same credential in use, that is a signal the authenticator may have been cloned. It is not a complete defence on its own, and some authenticators keep the counter at zero, but where present it gives the relying party a way to notice duplication across logins.

Attestation

Attestation answers a question the relying party may care about: what kind of authenticator is this. During registration, the authenticator can include an attestation statement, signed evidence about its make, model, and security properties, which the relying party can verify against known metadata.

There are several attestation formats and conveyance modes. In broad terms:

• None. No attestation is conveyed. Common and appropriate for consumer sign-in, where the site does not need to know the device brand.
• Direct or basic. The authenticator provides a certificate chain identifying its model, which the relying party checks against a metadata service.
• Self. The credential attests to itself without a separate trust anchor.

For most consumer services, requesting no attestation is the right call. It respects privacy and keeps enrollment simple. For regulated or high-assurance environments that must guarantee only approved hardware is used, attestation lets the relying party enforce an allowlist of authenticator models.

What the relying party must verify

The server side is where WebAuthn deployments succeed or fail. A correct relying party, on each authentication, checks that the signature validates against the stored public key, that the challenge matches the one it issued, that the origin is exactly the expected one, that the relying party id hash matches, and that the user-presence flag is set. Skipping any of these weakens the guarantees the ceremony was designed to provide. Using a well-reviewed server library rather than hand-rolling this verification is strongly advised.

To see which authentication-stack components are currently under active exploitation, our Exploit Intelligence dashboard tracks live vulnerabilities across WebAuthn libraries, identity providers, and the surrounding login infrastructure, so you can prioritise the flaws that attackers are actually using.

User verification and discoverable credentials

Two more WebAuthn concepts show up in real deployments. User verification is the difference between merely confirming a human is present (a touch) and confirming who that human is (a biometric or PIN). A relying party can require user verification when it wants the stronger check, or accept mere presence for lower-friction cases. The authenticator reports which it did through flags in the signed data, so the server can enforce its policy.

Discoverable credentials, sometimes called resident keys, are what make usernameless login possible. Instead of the site telling the authenticator which credential id to use, the authenticator stores enough to find the right credential itself, so the user can start from a bare login screen and the authenticator offers the matching account. This is the mechanism that lets a passkey sign you in without typing a username first. Non-discoverable credentials, by contrast, need the server to supply the credential id, which keeps nothing on the authenticator but requires the user to identify themselves before the ceremony.

A walkthrough of what actually gets signed

The security properties become concrete once you look at the data the authenticator produces. During authentication the authenticator returns two blobs, and the relying party verifies a signature computed across them.

The first is the authenticator data. It begins with a hash of the relying party id, so the server can confirm the assertion was produced for its own identifier and not some other site. Next comes a flags byte, whose bits report whether the user was present (a touch happened) and whether the user was verified (a biometric or PIN succeeded), plus a bit that says whether attested credential data or extensions are included. After the flags comes the signature counter, the incrementing value used for clone detection.

The second is the client data. The browser assembles this and it records the type of ceremony (a create or a get), the exact challenge the server issued, and the origin the request ran on. The browser hashes this client data, and the authenticator signs the concatenation of the authenticator data and that hash with the private key.

So the single signature ties together four independent facts: the relying party id (through the authenticator data), the challenge and origin (through the client data hash), the user-presence and user-verification state (through the flags), and the counter. A verifier that checks all of them leaves an attacker no room. Change the origin and the client data hash changes, so the signature fails. Replay an old response and the challenge inside the client data does not match the one the server just issued. Strip the user-verification requirement and the flag byte gives the server a way to reject the attempt. This is why the guidance to use a reviewed server library matters so much: every one of these checks has to run, and skipping the origin comparison or accepting a stale challenge quietly reopens the exact holes the ceremony was built to close.

How it evolved from U2F

WebAuthn did not appear from nothing. Its direct ancestor is U2F, the FIDO Alliance's Universal Second Factor, which let a site add a hardware key as a second step after a password. U2F keys signed a challenge bound to an origin, so they already delivered the phishing resistance that makes the family valuable. What U2F did not do was stand on its own. It was always a second factor sitting behind a password, and its browser interface was a separate, narrower API.

FIDO2 generalized that work into two cleaner pieces. WebAuthn became a first-class W3C browser standard that could act as a second factor or as a primary, passwordless credential. CTAP2, the newer version of the Client to Authenticator Protocol, added the ability for an authenticator to store discoverable credentials and to perform user verification with a PIN or biometric on the key itself. Older U2F authenticators still work under WebAuthn through the CTAP1 compatibility path, which is why a security key bought years ago usually still registers on a modern WebAuthn site. The through-line across the whole history is origin-bound public-key signatures. Passkeys are the most recent layer: the same WebAuthn credentials, made discoverable and synchronized across a user's devices through a platform account, so the key survives losing a single phone.

WebAuthn compared with older authentication methods

It helps to place WebAuthn against the methods it is meant to replace or reinforce.

Method	Shared secret on server	Phishing resistant	Replay resistant	Notes
Password	Yes, a hash	No	No	Reusable, guessable, breached in bulk
TOTP authenticator app	Yes, a seed	No	Within a time step	Code can be phished in real time
SMS one-time code	Yes, at the provider	No	Within the code's life	Vulnerable to SIM swap and interception
Push approval	No secret shared	Weakly	Yes	Prone to approval fatigue
WebAuthn	No, only a public key	Yes	Yes	Private key never leaves the authenticator

The row that matters is the first column. Every method above WebAuthn leaves a secret on the server that a breach can expose and an attacker can phish. WebAuthn stores only a public key, which is useless to steal. That single structural difference is why it belongs at the top of an authentication roadmap rather than as one more code to type.

Common mistakes and misconceptions

A few misunderstandings cause most of the trouble in real deployments.

Treating the credential id as a secret. The credential id is an identifier, not a secret. It travels in the clear and the server uses it to look up the matching public key. Security comes from the private key inside the authenticator, so there is no need to protect the credential id as though it were a password.

Verifying the signature but not the origin. A signature can be perfectly valid and still come from an attacker's relayed session if the server never checks that the origin in the client data is its own. Origin verification is the phishing defense, and it is the check most often dropped by hand-rolled server code.

Assuming attestation is required. Attestation identifies the make and model of the authenticator. It is optional and, for consumer login, usually undesirable because it adds friction and privacy exposure. A service that requests attestation without a metadata service to check it against and a policy to enforce gains nothing.

Relying on the counter alone. The signature counter is a clone-detection signal, not a primary control. Many platform authenticators and passkey providers keep the counter at zero, so a server that hard-fails on a non-advancing counter will lock out legitimate users. Treat it as one input to risk, not a gate.

Confusing user presence with user verification. A plain touch proves a human is present. A biometric or PIN proves which human. Requiring user verification when you only need presence adds friction, and accepting presence when you needed verification weakens the check. The flags byte reports which happened, so decide the policy deliberately and enforce it on the server.

Operational and detection signals

WebAuthn removes the phishing and replay problems, and it introduces its own operational surface to watch.

Account recovery is the usual soft spot. If losing a device drops a user back to an email link or a knowledge question, an attacker will target that fallback rather than the credential. Recovery paths deserve the same scrutiny as the primary login, because they define the real strength of the account. Watch for a spike in recovery flows, which can indicate an attacker probing the weakest door.

On the server, log the authenticator metadata you do collect: the credential id used, the user-verification state reported, and the counter value. A sudden appearance of many new credential registrations on one account, a counter that jumps in a way inconsistent with the device, or authentications that stop presenting user verification when they used to, are all worth an alert. None is proof of compromise on its own, and each is a thread worth pulling in an investigation.

Frequently asked questions

Is WebAuthn the same thing as a passkey? No. WebAuthn is the browser API and protocol. A passkey is a WebAuthn credential that is discoverable and, in most implementations, synchronized across a user's devices through a platform account. Every passkey uses WebAuthn, and not every WebAuthn credential is a passkey. A hardware security key bound to a single device is a WebAuthn credential that is not synchronized.

Can a WebAuthn credential be phished? The credential itself cannot be phished, because the private key never leaves the authenticator and the signature is bound to the origin. An attacker who stands up a look-alike site cannot obtain a signature that validates for the real site, since the origin in the signed client data would be the attacker's domain. The residual risk moves to account recovery and to any weaker fallback method the account still allows.

What happens if I lose my only authenticator? You fall back to whatever recovery the service offers. This is why registering more than one authenticator is the standard advice, and why synchronized passkeys exist: they let the credential survive the loss of a single device by living in a platform account across several devices. For high-value accounts, a second hardware key kept separately is a robust backup.

Does WebAuthn work without a password at all? Yes. With discoverable credentials and user verification, WebAuthn can be the sole factor, since it proves possession of the private key and presence or identity of the user in one step. Many services still keep a password during a transition period, then retire it once passkey coverage is broad enough.

Why does the relying party id matter so much? The relying party id scopes a credential to a site and is folded into what the authenticator signs. It is what stops a credential created for one domain from being used at another, and its hash inside the authenticator data lets the server confirm an assertion was meant for it. Setting it correctly, usually to the registrable domain, is essential to both the scoping and the phishing resistance.

Is attestation a privacy problem? It can be. Attestation reveals the make and model of the authenticator, and in some formats a batch of devices shares a certificate to avoid identifying an individual unit. For consumer login, requesting no attestation avoids the concern entirely. Reach for it only where a compliance or assurance need genuinely requires pinning approved hardware.

Can one authenticator hold credentials for many sites? Yes. An authenticator generates a separate key pair per relying party, so a single security key or platform authenticator can hold distinct credentials for a large number of sites, each scoped to its own origin and unusable anywhere else.

Why it holds up

WebAuthn's strength is that its security does not rest on user vigilance or on a secret that can be phished. The private key never leaves the authenticator, the challenge blocks replay, and the origin binding means a credential only works at the site that created it. Layer WebAuthn under passkeys for everyday accounts and under hardware keys for the highest-value ones, and you replace the password with a login that resists the attacks passwords never could. It pairs naturally with the step-up controls in the Two-Factor Authentication Guide, and in most cases replaces them outright.

Related guides

• Passkeys Explained
• Best Hardware Security Keys
• Two-Factor Authentication Guide
• How Digital Signatures Work