Key takeaways
WebAuthn is the W3C web standard that defines how browsers handle passwordless authentication. It provides two JavaScript methods: navigator.credentials.create() for registration and navigator.credentials.get() for login.
WebAuthn is one half of FIDO2. It handles the browser-to-website communication while Client to Authenticator Protocol (CTAP2) handles the browser-to-authenticator communication. Together, they enable end-to-end passwordless authentication.
Credentials are cryptographically bound to specific domains, which means they cannot be phished, replayed, or reused across sites. The private key never leaves the authenticator.
Every major browser and operating system supports WebAuthn—including Chrome, Safari, Firefox, Edge, Windows, macOS, iOS, and Android.
What is WebAuthn?
WebAuthn is a W3C standard that gives browsers a JavaScript API for strong, phishing-resistant authentication. It lets websites request cryptographic proof of a user's identity instead of asking for a password.
WebAuthn is the browser-facing half of FIDO2. When a user registers or logs in to a website using a fingerprint, face scan, or security key, the browser uses the WebAuthn API to coordinate the exchange between the website (the relying party) and the user's authenticator. The other half, CTAP2, handles the communication between the browser and external authenticators like USB security keys.
WebAuthn was published in March 2019. It is supported in every major browser and is the standard behind passkeys, platform authenticators like Windows Hello and Touch ID, and hardware security key login on the web.
Core characteristics:
Passwordless: eliminates the need for traditional passwords.
Phishing-resistant: credentials are bound to specific domains.
Standards-based: published by W3C as an open web standard.
Cryptographic: uses public key cryptography for authentication.
What does WebAuthn do?
WebAuthn is the piece of the FIDO2 authentication process that runs inside the browser. When a website wants to verify a user's identity without a password, it calls the WebAuthn API, and the browser takes over from there. It coordinates the exchange between the website and whatever authenticator the user has: a fingerprint sensor, a hardware security key, a face scan, or a passkey stored on their device.
From the user's perspective, the experience is simple. They visit a website, the browser prompts them to scan a fingerprint or tap a key, and they're in. Behind the scenes, WebAuthn is handling the cryptographic exchange that proves the user's identity without transmitting a password or any shared secret.
Two JavaScript methods power the entire API:
navigator.credentials.create() handles registration, the one-time step where the user's device generates a new credential for a website.
navigator.credentials.get() handles authentication, the login step where the device proves the user's identity by signing a challenge.
The browser does the heavy lifting. As a result, websites don't need to build cryptographic logic, and users don't need to install anything. WebAuthn is already built into Chrome, Safari, Firefox, Edge and other major browsers.
How does WebAuthn fit into FIDO2?
WebAuthn is one half of FIDO2. It handles the communication between the website and the browser. The other half, CTAP2, handles the communication between the browser and external authenticators like USB security keys or phones connected via Bluetooth.
Together, WebAuthn and CTAP2 cover the full chain—website to browser to authenticator and back. When the authenticator is built into the device (as with Touch ID, Windows Hello, and Android biometrics), WebAuthn handles the entire flow on its own because the browser can talk to the authenticator directly. CTAP2 becomes necessary only when the authenticator is a separate physical device.
WebAuthn was published as a W3C Recommendation (Level 1) in March 2019 with Level 2 following in April 2021. It is an open standard, allowing any browser vendor or website to implement it without licensing or permission. WebAuthn has become the dominant authn standard for modern web applications.
Why was WebAuthn created?
WebAuthn was created to strengthen authentication by replacing passwords. Passwords are the weakest link in web authentication because they can be phished on fake websites, stolen in server breaches, guessed through brute force, and reused across services so that a single compromise cascades into many.
The W3C and the FIDO Alliance built WebAuthn to eliminate these vulnerabilities at the browser level. Rather than layering more protections on top of passwords, they replaced the underlying mechanism entirely.
Password reuse eliminated: each service gets a unique cryptographic key pair.
Phishing defeated: credentials are domain-bound and cannot be entered on fake sites.
Server breaches defanged: no shared secrets stored on servers.
Weak credentials removed: cryptography replaces human password creation.
How does registration work in FIDO2/WebAuthn?
Registration (also called the registration ceremony or credential creation) is the one-time process where a user creates new credentials with a website. Three participants are involved: the relying party (the website), the client (the browser, which exposes the WebAuthn API), and the authenticator (the device or security key that creates and stores the credential).
1. The relying party creates a challenge
The relying party starts the registration by sending a unique, one-time request to the browser. This request identifies the website and includes a piece of data the authenticator will include when it creates the new credential. Using fresh data each time ensures that a registration can't be faked by replaying an old one.
2. The browser prompts the user
The browser asks the user to allow it to create a credential. Depending on the authenticator, this means scanning a fingerprint, completing a face scan, entering a PIN, or tapping a security key. Explicit user consent is required by the WebAuthn specification for both privacy and security. No credential can be created silently.
3. The authenticator generates a key pair
The authenticator generates a unique public-private key pair for this specific website. The public key will be shared with the relying party. The private key stays on the authenticator, protected by secure hardware, and is never transmitted.
Credentials can be stored in two ways. A resident key (also called a discoverable credential) is stored directly on the authenticator, allowing the authenticator to identify the user without the website providing a credential ID first. A non-resident key requires the website to identify the user and provide the credential ID before the authenticator can respond. Passkeys are resident keys that can sync across devices.
4. The relying party stores the public key
The authenticator sends the public key and metadata (including an attestation statement about the authenticator's properties) back to the browser, which forwards them to the relying party. The relying party stores the public key in its database while the private key remains on the authenticator. Registration is complete, and the user can now authenticate with this credential.
How does authentication work in the WebAuthn API?
Authentication is what happens every time the user comes back and logs in, and the website needs to confirm this is the same person who registered. It does that by asking the authenticator to prove it still holds the private key without ever seeing the key itself.
1. The relying party sends a challenge
The website generates a unique, single-use challenge and sends it to the browser. Think of it as a question only the right authenticator can answer. Each login attempt gets a fresh challenge, so an attacker who records one login can't replay it later.
2. The user confirms their identity
The browser prompts the user to verify themselves—a fingerprint scan, face scan, PIN, or tap on a security key. The WebAuthn specification distinguishes between two levels here. User presence means a human is physically there (a tap on a key). User verification means the system confirmed which human (a fingerprint match). The website decides which level it requires.
3. The authenticator signs the challenge
The authenticator takes the challenge and signs it with the private key. The signed response (called an assertion) includes the signature, information about the authenticator, and data confirming which website requested it. Only the authenticator that holds the private key for this credential can produce a valid signature.
4. The relying party checks the signature
The website uses the public key it stored during registration to verify the signature. If the math checks out, the challenge matches the one that was sent, and if the request came from the right domain, the user is authenticated. No password was involved at any step. The private key never left the device. The website only ever saw the public key and the signed response.
Passkeys, resident keys, and WebAuthn terms, explained
WebAuthn introduces several technical terms. Here are the ones that come up most often:
Passkeys: the user-friendly name for discoverable WebAuthn credentials that can sync across devices. Passkeys are a specific implementation of WebAuthn, not a separate standard. When someone asks "WebAuthn vs passkey," the answer is that passkeys are built on WebAuthn.
Resident keys (discoverable credentials): credentials stored directly on the authenticator. The authenticator can identify the user without the website providing a credential ID first, which enables true passwordless login where the user doesn't even type a username.
Non-resident keys: credentials where the website must first identify the user (typically by username) and provide the credential ID to the authenticator. The authenticator then locates the matching private key and signs the challenge.
Authenticator: the hardware or software component that creates and stores credentials. This can be a hardware security key, a platform authenticator, or a mobile device acting as a hybrid authenticator.
Relying party: the website or application requesting authentication. In WebAuthn, the relying party is identified by its domain, which is how credentials get bound to specific sites.
Attestation: cryptographic proof of the authenticator's properties and manufacturer. During registration, the authenticator can provide an attestation statement that lets the relying party verify the make and model of the authenticator. Attestation is optional, and many deployments skip it.
User verification: the process of confirming the specific user's identity through biometrics, a PIN, or a device password. Stronger than user presence alone.
User presence: confirmation that a human is physically present, typically by tapping a security key. Does not confirm which human.
Which platforms and browsers support WebAuthn?
WebAuthn enjoys broad support across modern browsers and operating systems. Developers can check for support programmatically by testing for the window.PublicKeyCredential interface in JavaScript. Developers can also test their browser's WebAuthn support at webauthn.io, a demonstration site maintained by Cisco Duo. Testing tools and WebAuthn test resources are available for verifying implementations across authenticator types before production deployment.
Platform / browser | WebAuthn support | Notes |
|---|---|---|
Chrome / Edge | Full support | Platform and roaming authenticators |
Safari | Full support | Modern iOS and macOS versions |
Firefox | Full support | All platforms |
Android | Full support | Modern Android versions with biometric or screen lock |
iOS | Full support | Modern iOS versions with Face ID or Touch ID |
Windows | Full support | Windows Hello integration |
macOS | Full support | Touch ID integration |
Last verified: June 2026
How do I implement the WebAuthn API?
Implementing WebAuthn involves client-side JavaScript (the browser API) and server-side validation (verifying the cryptographic responses). Here is a high-level overview of the process.
1. Check browser compatibility
Before attempting WebAuthn, verify that the user's browser supports it. Feature detection is straightforward:
Check for window.PublicKeyCredential in JavaScript. If it exists, the browser supports WebAuthn. If it doesn't, fall back to an alternative authentication method. For manual testing across authenticator types, webauthn.io is a useful starting point before production deployment.
2. Use the credential management interface
The WebAuthn API provides two methods that handle core operations:
navigator.credentials.create(): initiates the registration ceremony. The relying party passes a configuration that includes the challenge, user information, relying party details, and authenticator selection criteria. The browser coordinates with the authenticator to generate a new credential.
navigator.credentials.get(): initiates the authentication ceremony. The relying party passes the challenge and a list of acceptable credential IDs. The browser coordinates with the authenticator to sign the challenge with the matching private key.
These methods handle the complex cryptographic operations automatically. The developer configures the parameters while the browser and authenticator handle the rest.
3. Configure server-side validation
The server must validate both registration and authentication responses according to the WebAuthn specification. During authentication, the server verifies the signature's mathematical validity, confirms the challenge matches the one that was issued, checks that the origin matches the relying party's domain, and confirms the authenticator data flags meet the configured requirements.
The specification defines a step-by-step procedure for authentication responses. Libraries and SDKs are available in most major languages (Python, Node.js, Java, Go, .NET, for example) to simplify server-side FIDO2/WebAuthn implementation rather than having to build the validation logic from scratch.
4. Test authentication with sample keys
Test thoroughly with multiple authenticator types before production deployment:
Hardware security keys over USB and NFC.
Platform authenticators using built-in biometrics or device unlock.
Mobile devices acting as hybrid authenticators via Bluetooth.
Test edge cases—such as lost authenticators, multiple credentials per user, cross-platform login (registering on a laptop, authenticating from a phone, for example), and the behavior when a user’s only registered authenticator is unavailable. Use WebAuthn test tools and sandbox environments to validate before going live.
What are the security advantages of WebAuthn vs. passwords?
WebAuthn offers a security advantage by eliminating entire categories of attacks that target passwords.
The table below compares passwords with WebAuthn's FIDO2 authentication in terms of their resistance to several common security vulnerabilities.
Potential vulnerability | Traditional passwords | WebAuthn authentication |
|---|---|---|
Phishing | Vulnerable: users can be tricked into entering passwords on fake sites | Resistant: credentials are cryptographically bound to specific domains |
Server breach | High: password hashes can be stolen and cracked | Low: only public keys stored on servers, useless without private keys |
Credential reuse | Common: users reuse passwords across sites | Impossible: unique key pair generated per site |
Brute force attacks | Vulnerable: weak passwords can be guessed | Not applicable: cryptographic keys cannot be guessed |
Man-in-the-middle | Vulnerable: passwords can be intercepted | Resistant: cryptographic signatures verify origin |
User error | High: users create weak passwords | Minimal: cryptography handles security automatically |
The practical result: WebAuthn removes the user from the security equation. With passwords, security depends on the user making good choices (strong passwords, unique per site, never entered on a fake page, etc.). With WebAuthn, the cryptography enforces those properties automatically.
How can my company strengthen security with WebAuthn?
WebAuthn provides the browser standard for phishing-resistant authentication. Deploying it at scale requires a web authentication service that handles policy enforcement, authenticator management, and integration with existing systems.
Cisco Duo supports the full WebAuthn passkey specification as part of its phishing-resistant MFA and passwordless authentication platform:
Phishing-resistant MFA: WebAuthn security keys and platform authenticators enable passwordless authentication while mitigating the methods attackers use to steal SMS- and email-based MFA.
Seamless integration: works with existing systems and supports the full WebAuthn API specification.
User-friendly experience: provides intuitive login flows that users can adopt quickly.
Identity intelligence: combines WebAuthn authentication with device health checks and adaptive access policies.
Flexible deployment: supports platform authenticators, roaming authenticators, and synced passkeys, including discoverable credentials.
Where is WebAuthn headed?
Passkeys are becoming the default sign-in method across the web, and WebAuthn is the standard making that possible. According to a 2024 FIDO Alliance survey of executives at companies with 500 or more employees, 87% have either successfully deployed or are currently deploying enterprise passkeys, up 14 percentage points from prior years.
Browser and platform support has reached a point where WebAuthn is no longer an emerging standard—it is the default authentication API across every major browser and operating system. As passkey adoption accelerates, the focus is shifting from whether to implement WebAuthn to how quickly organizations can enforce it at scale.
For enterprises, that means connecting WebAuthn to broader identity infrastructure. Duo Directory enables passwordless enforcement alongside SAML and OIDC federation, giving organizations a path to require WebAuthn-based authentication across cloud applications, on-premises systems, and everything in between without rebuilding their existing identity architecture.
Start your free trial to experience passwordless authentication in practice.