WebAuthn / FIDO2

What it is

WebAuthn is the W3C browser API for public-key authentication, and FIDO2 is the broader FIDO Alliance specification set: WebAuthn plus CTAP, the protocol that talks to authenticators. Together they are the foundation of passkeys and hardware security keys, and they make phishing-resistant authentication practical at scale. The relying party (your site) stores only a public key, and the authenticator signs a fresh challenge that is bound to your origin, so there is no reusable secret to phish or leak.

Status (November 2026)

Level 3 went from a Candidate Recommendation Snapshot on 26 May 2026 to Recommendation with, in the W3C's words, "no substantive changes." Its editors are Tim Cappalli (Okta), Akshay Kumar (Microsoft), Emil Lundberg (Yubico), Matthew Miller (Cisco), Pascoe (Apple) and Nina Satragno (Google). CTAP dates above come from the document identifiers on the FIDO Alliance download page; the FIDO patent promise applies at Proposed Standard, not Working Draft.

How it works

Registration (create)

1. The relying party generates a random challenge and calls navigator.credentials.create() with its RP ID (a registrable domain such as example.com), a user handle, acceptable algorithms, and preferences such as residentKey and userVerification.
2. The browser builds clientDataJSON containing the challenge, the calling origin and the ceremony type, and passes a hash of it to the authenticator, over CTAP if the authenticator is external.
3. The authenticator asks for a user gesture (touch, biometric or PIN), generates a new key pair scoped to the RP ID, and returns the public key, a credential ID and authenticatorData with flags: user present (UP), user verified (UV), backup eligible (BE) and backup state (BS). It may include an attestation statement.
4. The relying party verifies the challenge, the origin, the RP ID hash and the flags, optionally validates attestation, and stores the credential ID, public key, signature counter and backup flags against the account.

Authentication (get)

1. The relying party sends a new challenge via navigator.credentials.get(), either with a list of allowed credential IDs or empty, so the user can pick a discoverable credential (a passkey).
2. The authenticator finds the credential for this RP ID, gets the user gesture, and signs authenticatorData plus the hash of clientDataJSON.
3. The relying party verifies the signature with the stored public key, checks the challenge, origin, RP ID hash and UV flag, and starts a session.

Origin binding is the security property. The browser writes the real origin into clientDataJSON and the authenticator only releases a credential for the matching RP ID. A lookalike domain gets nothing usable, which is why adversary-in-the-middle phishing proxies fail against WebAuthn when the relying party checks the origin.

Level 3 features practitioners meet

The Level 3 text defines several capabilities worth knowing about: getClientCapabilities() to ask the browser what it supports; parseCreationOptionsFromJSON() and parseRequestOptionsFromJSON() so servers can send options as JSON; signal methods (signalUnknownCredential, signalAllAcceptedCredentials, signalCurrentUserDetails) that let a site tell a passkey provider a credential was deleted or a user renamed; user-agent hints; related origins, so one passkey can work across a set of your domains; the BE and BS backup flags, which tell you whether a credential is a synced passkey; topOrigin for cross-origin iframes; and the prf and largeBlob extensions.

Synced versus device-bound

Microsoft's guidance is to treat synced passkeys as phishing-resistant but "with the same security posture as other unattested authenticators." That is a useful default for any relying party: allow synced passkeys broadly, and require attested, device-bound credentials (filtered by AAGUID) for privileged roles.

Common implementation mistakes and attacks

Related standards

OpenID Connect and SAML carry the result of a WebAuthn login from your IdP to applications, and OIDC's amr and acr claims are how an app learns a passkey was used. NIST SP 800-63 requires phishing-resistant authenticators at the highest authenticator assurance level (AAL3). Device Bound Session Credentials target the post-login session that WebAuthn does not cover. FAPI 2.0 and OAuth 2.1 cover the API tokens issued afterwards.

Who implements it

• Authenticators: platform authenticators in Apple, Google and Microsoft operating systems; hardware keys such as the Yubico YubiKey 5 Series, which lists FIDO2 alongside U2F, smart card, OTP and OpenPGP on its product page; and password managers acting as passkey providers, such as 1Password and Bitwarden, which Microsoft's Entra documentation names as supported synced passkey providers.
• Relying parties and IdPs: Microsoft Entra ID supports synced passkeys and device-bound passkeys on FIDO2 security keys and in Microsoft Authenticator, in all editions including Free, with passkey profiles that set attestation, passkey type and AAGUID allow or block lists per group.
• For the wider market, see MFA and passwordless vendors, the MFA matrix, and SWI's Phishing-Resistant MFA Matrix 2026.

When to use it

For any account where phishing and account takeover matter, which is most of them. Synced passkeys suit consumers; device-bound passkeys and hardware keys suit high-value and workforce use. Plan enrollment, a second authenticator per user, and recovery before you remove passwords, because those are the steps attackers target next.

How it works, message by message

The WebAuthn message-flow walkthrough decodes both ceremonies: creation options, the attestation response, clientDataJSON, authenticator data byte by byte and flags, request options and the assertion, with each field tied to its Level 3 section and the relying party checks from §7.1 and §7.2. Try a ceremony in the WebAuthn tester.

Related

Guides: Passkeys 101, implementing passkeys in the enterprise, what is passwordless, MFA implementation best practices. Glossary: FIDO2, WebAuthn, passkey, relying party.

Who wrote it

The WebAuthn specification is edited by a group including Tim Cappalli and Emil Lundberg, with John Bradley a long-standing co-author across WebAuthn and FIDO2. The hardware lineage runs back to Stina Ehrensvard, who co-invented the YubiKey, and adoption was driven by the FIDO Alliance under Andrew Shikiar. More in the experts directory.