WebAuthn · Lablypedia

To use WebAuthn, users require a compatible authenticator. The standard does not specify how to store the keys required for signing, so a variety of authenticator types can be used. The most common authenticator type is a platform authenticator, which is built into the operating system of the device. Common platform authenticators include Android, Apple Keychain and Windows Hello. These make use of hardware security features (such as TEE and TPM), and often sync credentials between devices for ease-of-use. Another common authenticator type is a roaming authenticator, where a separate hardware device authenticates the user by connecting over USB, Bluetooth Low Energy, or near-field communications (NFC). Most smartphones can be used as roaming authenticators, and dedicated physical security keys are also used. WebAuthn is effectively backward compatible with FIDO Universal 2nd Factor (U2F) as they both use the CTAP protocol. Password managers can also be used as an authenticator, often with cloud sync. Where credentials sync is not viable or possible, WebAuthn Hybrid Transport can be used to access credentials stored on another authenticator such as a smartphone.

Like legacy U2F, WebAuthn is resistant to some phishing attacks as the authenticator only offers credentials that were registered on the same website. However, unlike U2F, WebAuthn can be implemented in a passwordless manner. Moreover, a roaming hardware authenticator resists malware, since the keys are stored on a separate device, which prevents the malware from accessing them directly.

The WebAuthn Level 1 and 2 standards were published as W3C Recommendations on 4 March 2019 and 8 April 2021 respectively. A Level 3 specification progressed through several Candidate Recommendation Snapshots during 2026, and in July 2026 the W3C proposed advancing it to full Recommendation status.

Background

The combination of username and password has been the standard mechanism for users to prove to a website that they are a specific person since the dawn of web-based services. However, password-based authentication has been known to be flawed for many years, even decades, with most issues relating to poor practices on either the user side or the server side.

Users routinely reuse passwords across services (which exposes them to credential stuffing), choose weak passwords that can be brute-forced and predicted in a short amount of time, and store them in insecure ways that allows for their disclosure (for example writing them down on a piece of paper or a document), with each of those contributing to the likelihood of credentials and account compromise.

Likewise, servers often deal with passwords improperly, both while storing them in databases, and while processing them. Common flaws include plaintext storage, lack of salted hashing (or more advanced schemes for at-rest credentials), arbitrary restrictions on password length and charset, mandatory ineffective password changes, and deliberate incompatibility with password managers (for instance, by preventing passwords to be pasted).

As a result, in 2012, Google alongside Yubico started working on a standard called Universal 2 Factor (U2F) that would allow websites to programatically verify a second-factor about the user by verifying the presence of hardware-based tokens (like smart cards) on the user. This standard was considered an improvement over existing solutions like time-based one-time password (TOTP) or SMS-based authentication that still left the user vulnerable to sophisticated phishing campaigns. The standard was later adopted into a larger industry wide collaboration called the FIDO (Fast IDentity Online) Alliance. The first draft for this proposed standard was published in 2014. In 2015, the FIDO Alliance started developing the FIDO 2 Project, releasing a proposed standard where they sought to improve upon the existing U2F standard by addressing many of its weaknesses. For example, the U2F standard still required to use of passwords alongside a second factor which still left websites vulnerable to password leaks and other similar attacks that were common against passwords. Additionally, the U2F specification only verified the second factor device and did not perform any user authentication. This meant that if the second factor device had been stolen or lost anyone with access to the U2F device would be able to bypass the second factor of authentication for accounts linked to the device.

In November 2015, the FIDO Alliance submitted the first version of FIDO 2 to the World Wide Web Consortium as a proposed web standard. In 2016, the W3C established a separate W3C Web Authentication Working Group to help write a standard for the new FIDO 2 project's authentication framework such that it could be integrated into browsers by default. The standard was adopted by major browser vendors in late 2018 and early 2019, with Chrome supporting the standard in version 67, Firefox in version 60 and Safari in version 13. In 2019, the FIDO 2 project alongside the W3C Web Authentication Working Group released the first version of the WebAuthn specification based on the FIDO 2 project as a W3C recommendation. Subsequently, the standard has gone through two revisions, being called Level 1, Level 2 with a Level 3 revision still being considered a Candidate Recommendation as of June 2026, meaning that it is considered mature and feature complete and is ready for implementation and testing by interested parties.

5 more chapters are free with a Lably account.

Passkey branding

Passkey is the de facto non-technical term for a saved sign-in credential, a piece of cryptographic information that is capable of being used to authenticate a user using the WebAuthn standard. Most user interfaces that support using WebAuthn refer to it as supporting passkeys.

Due to the open-ended nature of the WebAuthn specification, a passkey can be stored on software or hardware that is capable of authenticating a user. This includes technology like Windows Hello which works by using facial recognition to authenticate users, Bitwarden which authenticates users through a browser extension or YubiKeys that allow a user to authenticate using a physical hardware token. The cryptographic keys stored by the software are only available to use for the browser once the software or hardware is authenticated the user.

When Apple first prominently introduced passkeys to the public in 2022, they emphasized integrations with their own products. This, combined with the lack of clear communication from other companies, led to speculation that passkeys were proprietary to Apple. As browsers and websites began to implement WebAuthn, the inconsistent feature-sets have often resulted in a variety of understandings of what exactly counted as a passkey.

Overview

Like its predecessor FIDO U2F, W3C Web Authentication (WebAuthn) involves a website, a web browser, and an authenticator:

The website is a conforming WebAuthn Relying Party
The browser is a conforming WebAuthn Client
The authenticator is a FIDO2 authenticator, that is, it is assumed compatible with the WebAuthn Client

WebAuthn specifies how a claimant demonstrates possession and control of a FIDO2 authenticator to a verifier called the WebAuthn Relying Party. The authentication process is mediated by an entity called the WebAuthn Client, which is little more than a conforming web browser.

Level 3

WebAuthn Level 3 introduces several capabilities beyond authentication alone. The PRF (Pseudo-Random Function) extension allows a passkey to derive encryption keys, enabling it to help protect encrypted data such as backups without a separate password. Related Origin Requests (ROR) let a single passkey be used across multiple domains belonging to the same organization, reducing the need for duplicate credentials.

The specification also added a section addressing the privacy implications of using WebAuthn credentials across origins, including risks associated with cross-origin iframes.

Authentication

Authenticator is a multi-factor cryptographic authenticator that uses public-key cryptography to sign an authentication assertion targeted at the WebAuthn Relying Party. Assuming the authenticator uses either a facial recognition, fingerprint or PIN for user verification, the authenticator itself is something you have while the facial recognition and fingerprint (biometric) are something you are and the PIN is something you know.

To initiate the WebAuthn authentication flow, the WebAuthn Relying Party indicates its intentions to the WebAuthn Client (i.e., the browser) via JavaScript. The WebAuthn Client communicates with the authenticator using a JavaScript API implemented in the browser. A roaming authenticator conforms to the FIDO Client to Authenticator Protocol (CTAP), and connected over USB, Bluetooth Low Energy, or near-field communications (NFC).

WebAuthn does not strictly require a roaming hardware authenticator. Alternatively, a software authenticator (e.g., implemented on a smartphone) or a platform authenticator (i.e., an authenticator implemented directly on the WebAuthn Client Device) may be used. Relevant examples of platform authenticators include Windows Hello and the Android operating system.

WebAuthn Hybrid Transport allows the WebAuthn Client to access credentials stored on another authenticator such as a smartphone, useful in certain situations where credential sync is not viable.

There is a lingering misunderstanding among users that biometric data is transmitted over the network in the same manner as passwords, which is not the case.

Registration

When the WebAuthn Relying Party receives the signed authentication assertion from the browser, the digital signature on the assertion is verified using a trusted public key for the user.

To obtain a public key for the user, the WebAuthn Relying Party initiates a WebAuthn registration flow that is similar to the authentication flow illustrated above. The primary difference is that the authenticator now signs an attestation statement with its attestation private key. The signed attestation statement contains a copy of the public key that the WebAuthn Relying Party ultimately uses to verify a signed authentication assertion. The attestation certificate contains metadata describing the authenticator itself.

The digital signature on the attestation statement is verified with the trusted attestation public key for that particular model of authenticator. How the WebAuthn Relying Party obtains its store of trusted attestation public keys is unspecified. One option is to use the FIDO metadata service.

The attestation type specified in the JavaScript determines the trust model. For instance, an attestation type called self-attestation may be desired, for which the trust model is essentially trust on first use.

Support

The WebAuthn Level 1 standard was published as a W3C Recommendation by the Web Authentication Working Group on 4 March 2019. WebAuthn is supported by Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari and Opera.

The desktop version of Google Chrome has supported WebAuthn since version 67. Firefox, which had not fully supported the previous FIDO U2F standard, included and enabled WebAuthn in Firefox version 60, released on 9 May 2018. An early Windows Insider release of Microsoft Edge (Build 17682) implemented a version of WebAuthn that works with both Windows Hello as well as external security keys.

Existing FIDO U2F security keys are largely compatible with the WebAuthn standard, though WebAuthn added the ability to reference a unique per-account "user handle" identifier, which older authenticators are unable to store.

One of the first FIDO2-compatible authenticators was the second-generation Security Key by Yubico, announced on 10 April 2018. The first FIDO2-compatible authenticators with a display was Trezor Model T by SatoshiLabs, announced on 6 November 2019. Trezor Model T was also the first authenticator that allowed users to select which FIDO2 resident credential should be used directly on a device.

The first Security Level 2 certified FIDO2 key, called "Goldengate" was announced one year later by eWBM on 8 April 2019.

Dropbox announced support for WebAuthn logins (as a 2nd factor) on 8 May 2018.

Apple announced that Face ID or Touch ID could be used as a WebAuthn platform authenticator with Safari on 24 June 2020.

Several password managers such as Bitwarden and Dashlane support WebAuthn.

API

WebAuthn implements an extension of the W3C's more general Credential Management API, which is an attempt to formalize the interaction between websites and web browsers when exchanging user credentials. The Web Authentication API extends the Credential Management navigator.credentials.create() and navigator.credentials.get() JavaScript methods so they accept a publicKey parameter. The create() method is used for registering public key authenticators as part of associating them with user accounts (possibly at initial account creation time but more likely when adding a new security device to an existing account) while the get() method is used for authenticating (such as when logging in).

To check if a browser supports WebAuthn, scripts should check if the window.PublicKeyCredential interface is defined. In addition to PublicKeyCredential, the standard also defines the AuthenticatorResponse, AuthenticatorAttestationResponse, and AuthenticatorAssertionResponse interfaces in addition to a variety of dictionaries and other datatypes.

The API does not allow direct access to or manipulation of private keys, beyond requesting their initial creation.

Reception

In August 2018, Paragon Initiative Enterprises conducted a security audit of the WebAuthn standard. While they could not find any specific exploits, they revealed some serious weaknesses in the way the underlying cryptography is used and mandated by the standard.

Main points of criticism revolve around two potential issues that were problematic in other cryptographic systems in the past, and therefore should be avoided in order to not fall victim to the same class of attacks:

Through the mandated use of COSE (RFC 8152) WebAuthn also supports RSA with PKCS1v1.5 padding. This particular scheme of padding has been known to be vulnerable to specific attacks for at least twenty years, and it has been successfully attacked in other protocols and implementations of the RSA cryptosystem in the past. It is difficult to exploit under given conditions in the context of WebAuthn, but since there are more secure cryptographic primitives and padding schemes, it is still a bad choice and cryptographers no longer consider it best practice.
The FIDO Alliance standardized on the asymmetric cryptographic scheme ECDAA. This is a version of direct anonymous attestation based on elliptic curves and in the case of WebAuthn is used to verify the integrity of authenticators, while also preserving the privacy of users, as it does not allow for global correlation of handles. However, ECDAA does not incorporate some of the lessons that were learned in the last decades of research in the area of elliptic curve cryptography, as the chosen curve has some security deficits inherent to this type of curve, which reduces the security guarantees quite substantially. Furthermore, the ECDAA standard involves random, non-deterministic signatures, which already has been a problem in the past.

Paragon Initiative Enterprises also criticized how the standard was initially developed, as the proposal was not made public in advance and experienced cryptographers were not asked for suggestions and feedback. Hence the standard was not subject to broad cryptographic research from the academic world.

Despite these shortcomings, Paragon Initiative Enterprises still encourage users to continue to use WebAuthn but have come up with some recommendations for potential implementers and developers of the standard that they hope can be implemented before the standard is finalized. Avoiding such mistakes as early as possible would protect the industry from any challenges that are introduced by broken standards and the need for backwards compatibility.

ECDAA was only designed to use in combination with device attestation. This particular feature of WebAuthn is not necessarily required for authentication to work. Current implementations allow the user to decide whether an attestation statement is sent during the registration ceremony. Independently, relying parties can choose to require attestation or not. ECDAA was removed from WebAuthn Level 2 as it was not implemented by browsers nor relying parties.