Web Authentication (WebAuthn) is a web standard from the W3C that gives websites a common browser API for creating and using public-key sign-in credentials. Instead of checking a password, the site asks the browser to create a credential on an authenticator, such as a phone, laptop or hardware security key, and later to prove possession of it by signing a challenge. WebAuthn is the web half of FIDO2, and it is the API behind passkeys on the web.
At a glance
- A W3C standard published in levels; Level 3 is the current Recommendation at the time of writing, with later work in draft.
- Websites (relying parties) call it from JavaScript; browsers and operating systems talk to the authenticator.
- Credentials are scoped to the site’s domain, and the browser enforces it, which is the basis for phishing-resistant MFA.
- Supports built-in (platform) authenticators and external (roaming) ones over USB, NFC, Bluetooth or a phone.
- Can be used as a second factor or for full passwordless authentication.
What problem it solves
Before WebAuthn, using a security key or device-based credential on the web meant browser-specific plugins or APIs. Most sites fell back to passwords plus SMS or app codes, which can be phished and stolen from server databases.
WebAuthn gives websites a common, browser-native way to use public-key credentials. The site stores only public keys, so a database breach doesn’t leak reusable sign-in secrets, and the browser binds each sign-in to the real domain, so a look-alike site gets no response it can replay. It also replaced the older U2F JavaScript API that early security keys used.
How it works
Relying party and RP ID. The website is the relying party. Each credential is bound to a relying party identifier, normally the site’s domain, set when the credential is created. The browser refuses to use a credential for a different domain.
Registration ceremony. The site’s server generates a random challenge and calls the browser’s credential creation function with details of the site and user. The browser passes the request to an authenticator, which creates a new key pair, keeps the private key and returns the public key. The server verifies the response and stores the public key against the user’s account.
Authentication ceremony. At sign-in, the server sends a fresh challenge. The browser includes the origin it is actually connected to, and the authenticator signs the challenge after checking user presence (a touch or tap) and, where requested, user verification (a PIN or biometric checked locally). The server verifies the signature and checks the flags and a signature counter where the authenticator provides one.
Attestation. Optionally, the authenticator returns attestation data at registration. A relying party that validates it against trusted vendor or FIDO Alliance metadata can identify the authenticator model and accept only approved ones; attestation can also be self-signed or absent, so it proves a model only when checked against trusted metadata. Organizations use it to restrict authenticators; consumer sites usually don’t request it.
Talking to authenticators. Platform authenticators are built into the device. Roaming authenticators connect through the FIDO Alliance’s Client to Authenticator Protocol (CTAP), including keys that only speak the older Universal 2nd Factor (U2F) protocol.
When it matters for buyers
- When choosing an identity provider. For staff sign-in, your identity provider (IdP) implements WebAuthn; what matters is which authenticators and policies it supports.
- When building or buying customer-facing apps. Passkey sign-in for customers means WebAuthn support in your app or customer identity platform.
- When asking software vendors about phishing-resistant sign-in. An app that supports single sign-on can usually inherit WebAuthn from the IdP; one with its own login needs native support.
- For shared devices. Roaming security keys work across computers; platform credentials stay with one device or sync account.
- When testing apps. WebAuthn implementations should be included in application security reviews, since server-side verification mistakes can weaken them.
Questions to ask vendors
- Does your product support WebAuthn sign-in directly, or only through single sign-on to our identity provider?
- Which authenticator types are supported: platform, security keys, cross-device phone sign-in?
- Can we require user verification (PIN or biometric) rather than presence alone?
- Do you support attestation and allow-lists of authenticator models?
- What fallback and recovery methods exist, and can we disable weak ones?
- Which WebAuthn server library or service do you use, and how is it kept current?
How it differs from FIDO2
FIDO2 is the umbrella name for two specifications. WebAuthn is the part websites use: the browser API and the rules for registering and verifying credentials. CTAP is the part between the browser or operating system and an external authenticator, published by the FIDO Alliance. A web developer works with WebAuthn; a security key maker implements CTAP. If you are building or testing your own sign-in flows, our application security testing overview covers checking implementations like these.