WebAuthn


Web Authentication is a web standard published by the World Wide Web Consortium. WebAuthn is a core component of the FIDO2 Project under the guidance of the FIDO Alliance. The goal of the project is to standardize an interface for authenticating users to web-based applications and services using public-key cryptography.
On the client side, support for WebAuthn can be implemented in a variety of ways. The underlying cryptographic operations are performed by an authenticator, which is an abstract functional model that is mostly agnostic with respect to how the key material is managed. This makes it possible to implement support for WebAuthn purely in software, making use of a processor's trusted execution environment or a Trusted Platform Module. Sensitive cryptographic operations can also be offloaded to a roaming hardware authenticator that can in turn be accessed via USB, Bluetooth Low Energy, or near-field communications. A roaming hardware authenticator conforms to the FIDO Client to Authenticator Protocol, making WebAuthn effectively backward compatible with the FIDO Universal 2nd Factor standard.
Similar to legacy U2F, Web Authentication is resilient to verifier impersonation, that is, it is resistant to active man-in-the-middle-attacks, but unlike U2F, WebAuthn does not require a traditional password. Moreover, a roaming hardware authenticator is resistant to malware since the private key material is at no time accessible to software running on the host machine.
The WebAuthn Level 1 standard was published as a W3C Recommendation on 4 March 2019. A Level 2 specification is under development.

Background

FIDO2 is the successor of the FIDO Universal 2nd Factor legacy protocol. FIDO2 authentication has all the advantages of U2F—the primary difference is that a FIDO2 authenticator can also be a single multi-factor authenticator. U2F protocol is designed to act as a second factor to strengthen existing username/password-based login flows.
A FIDO2 authenticator may be used in either single-factor mode or multi-factor mode. In single-factor mode, the authenticator is activated by a test of user presence, which usually consists of a simple button push. In multi-factor mode, the authenticator performs user verification. Depending on the authenticator capabilities, this can be:
In any case, the authenticator performs user verification locally on the device. A secret or biometric stored on the authenticator is not shared with the website. Moreover, a single secret or biometric works with all websites, as the authenticator will select the correct cryptographic key material to use for the service requesting authentication after user verification was completed successfully.
A secret and biometric on the authenticator can be used together, similarly to how they would be used on a smartphone. For example, a fingerprint is used to provide convenient access to your smartphone but occasionally fingerprint access fails, in which case a PIN can be used.

Overview

Like its predecessor FIDO U2F, W3C Web Authentication involves a website, a web browser, and an authenticator:
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.

Authentication

For the purposes of illustration, we assume the authenticator is a roaming hardware authenticator. In any case, the 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 a PIN for user verification, the authenticator itself is something you have while the PIN is something you know.
To initiate the WebAuthn authentication flow, the WebAuthn Relying Party indicates its intentions to the WebAuthn Client 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.
WebAuthn does not strictly require a roaming hardware authenticator. Alternatively, a software authenticator or a platform authenticator may be used. Relevant examples of platform authenticators include Windows Hello and the Android operating system.
The illustrated flow relies on PIN-based user verification, which, in terms of usability, is only a modest improvement over ordinary password authentication. In practice, the use of biometrics for user verification can improve the usability of WebAuthn. The logistics behind biometrics are still poorly understood, however. 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. How does the WebAuthn Relying Party obtain that trusted public key in the first place?
To obtain a public key for the user, the WebAuthn Relying Party initiates a WebAuthn registration flow that is very 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 statement also 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 the following web browsers: Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari and the Opera web browser.
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 May 9, 2018. An early Windows Insider release of Microsoft Edge 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 April 10, 2018.
The first Security Level 2 certified FIDO2 key, called "Goldengate" was announced one year later by eWBM on April 8, 2019. and
Dropbox announced support for WebAuthn logins on May 8, 2018.
Apple Safari announced that Face ID or Touch ID could be used as a WebAuthn platform authenticator on June 24, 2020.

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 while the get method is used for authenticating.
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 did 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.
The 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:
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 implementors and developers of the standard that they hope can be implemented before the standard is finalized. Avoiding such mistakes as early as possible would prevent the industry from any challenges that are introduced by broken standards and the need for backwards compatibility.
ECDAA was only designed used 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.