An Overview of WebAuthn

What is Webauthn?

WebAuthn or Web Authentication API is a specification of a JavaScript API that allows applications to perform secure authentication for both multi-factor and single-factor scenarios. The API, exposed by a compliant browser, enables applications to talk to authenticators such as key fobs or fingerprint readers. Using WebAuthn, applications can increase security to prevent phishing attacks and improve user experiences.

Moving Towards a Passwordless Web with Webauthn Protocol

Passwords are vulnerable. Since users must remember so many of them, they often reuse the same password across different applications or use weak passwords they can easily remember. Either way, such behavior means that it's fairly easy to break into somebody's account if it's guarded only by a password. Databases containing password lists are breached regularly, which worsens the problem.

Multi-factor authentication (MFA) was created as a response to password issues. With multi-factor authentication, in addition to checking the user's password, you may confirm possession of the account by entering a code sent through an SMS or generated by a specialized authenticator app. Accounts secured with multi-factor authentication are much better protected if somebody manages to steal your password. With MFA, an attacker would need to have access to your other factor to perform full authentication.

However, multi-factor authentication is vulnerable to a different attack vector: phishing. Even if you use a strong password and a second factor, you can still fall into the trap of entering your credentials on an attacker's website. According to Google Transparency Report, since 2016, phishing has been much more common on the web than using malware to steal passwords.

These problems have caused the industry to seek out new solutions to authenticate users securely — solutions that don't rely on passwords and are immune to phishing attacks. One such solution is FIDO2. Overseen by FIDO Alliance, FIDO2 is a set of standards that enable external authenticators, like key fobs, to perform user authentication. This standard was then adapted to the web through WebAuthn.

How Does WebAuthn Work?

To better understand WebAuthn ceremonies (authentication flows are called ceremonies in this standard), let's first look at the actors involved. If you're familiar with OAuth and OpenID Connect, you may find some familiar names, yet they have slightly different meanings.

A Relying Party is the application that performs the authentication of the user. In WebAuthn, the Relying Party is the whole application, consisting of a frontend part (e.g., a Single Page Application) and a backend (e.g., a web server). If you use an Authorization Server (or OpenID Connect Provider) to perform authentication, and you enable WebAuthn as a means of authenticating users, then your Authorization Server is the Relying Party.

A Client (or WebAuthn client) is the software that implements the Web Authentication API. In most cases, this will be a compliant web browser that exposes the API to a JavaScript application.

An Authenticator is a device that creates and stores user credentials. In a password-based authentication, the credentials (the passwords) are stored in the user's brain. In a WebAuthn scenario, the credentials are stored on a device. An authenticator can be a separate physical device, like a key fob connected to your computer via USB, Bluetooth, or NFC. It can also be embedded into the operating system, e.g., Windows Hello, or into a user agent. An authenticator can use interfaces to fingerprint readers or facial recognition sensors to confirm user credentials.

Previously, the only authenticators compatible with this specification were dedicated key fobs, which users had to acquire themselves. Such a solution was sufficient for the needs of corporations and security-savvy individuals. However, it definitely wasn't enough to reach a wider audience. Nowadays, FIDO2-compatible Authenticators are built into operating systems and mobile phones. Thus, you can use your mobile phone as a WebAuthn authenticator. The phone will use security features available on the device to protect your credentials. This could be a PIN to unlock the phone, or data from the fingerprint reader. Also, many browsers are now compatible with WebAuthn and offer built-in authenticators that can communicate with the operating system to authorize a user.

An important feature of an authenticator is that it connects with the client without using the Internet. You can use your mobile phone as an authenticator to log in to a website opened on your laptop, but the phone has to connect to your computer via Bluetooth (Bluetooth Low Energy, to be exact). This prevents any man-in-the-middle attacks on the data exchanged between the client and an authenticator. Thanks to this, the client can be sure it really communicates with the authenticator and that the data has not been tampered with.

Web Authentication Ceremonies

Web Authentication specifies two similar flows that the Relying Party can use for a secure authentication experience. First, the user must register new credentials. Once registration is complete, the verification of authentication assertion ceremony can be performed in a subsequent authentication request.

Registering New Credentials

To be able to use WebAuthn to authenticate, a user must first register their credentials with the Relying Party. The registration ceremony looks as follows:

1. First, the Relying Party (RP) makes a create request to the WebAuthn client, passing several options: among others, information about the Relying Party, ID of the authenticating user, and a challenge, which will be later used to verify the response from the authenticator. If the user already has an account registered with the Relying Party, the RP should first authenticate the user with a legacy method before it allows them to register new credentials for WebAuthn.

2. The request is proxied through the client to an authenticator. If more than one authenticator is available, the client will present a list to the user. An essential role of the client is to enrich the request with information about the origin of the creation request.

3. The user consents to create new credentials for the given Relying Party in the chosen authenticator.

4. The authenticator now creates a new set of credentials — a pair of private and public cryptographic keys. The public key is embedded in the response, together with other data (notably the origin that came in the request), and the whole response is signed. The authenticator sends the response back to the Relying Party. Again, the client is used as a proxy.

5. The Relying Party verifies the response from the authenticator. It can validate the authenticity of the authenticator and whether the response has been tampered with. The Relying Party also verifies the origin returned by the authenticator. It checks whether the value of the origin is one that it expects. This vital part of the ceremony is used to prevent phishing attacks. A request initiated from a forged website will have a different origin and thus will be rejected by the Relying Party.

6. Once the Relying Party deems the response valid, it saves the user data together with the public key returned by the authenticator. The registration is now complete.

Verification of Authentication Assertion Ceremony

Once the user registers their credentials with a Relying Party, they can use it in subsequent authentication attempts. The WebAuthn method can be used as a strong second factor, complementary to traditional password logins, or it can be used as a standalone method, where no password is needed. The authentication ceremony is similar to registration and looks as follows:

1. Again, the ceremony is initiated by the Relying Party, but this time by performing a GET request to the Web Authentication API. The Relying Party passes an options object containing information identifying the Relying Party, among other fields.

2. As in the registration ceremony, the client adds information about the request's origin, which can be later verified to prevent phishing.

3. The authenticator asks the user if they want to authenticate to the requesting Relying Party.

4. Upon confirmation, the authenticator sends back a response signed with the private key created during the registration ceremony. Here is the main difference between registration and authentication: this response does not contain any information about the previously generated public key.

5. The Relying Party receives the response and validates it. It uses the public key it stores to verify the signature of the response, which eventually verifies the authenticating user. Again, an essential role for the Relying Party is to verify the origin contained in the response. It should match an expected source to thwart any phishing attempts.

Examples of WebAuthn

Although the concept of WebAuthn ceremonies may sound a bit complicated at first, if you look at concrete scenarios, you'll realize that the solution creates an excellent user experience and retains a high level of security.

A common scenario for WebAuthn involves a user browsing websites on their phone. Once they create an account on a website (or log in with a legacy method, if they already have an account), the phone will prompt the user, "Do you want to register your device with this website?". If the user agrees, the phone will ask the user to confirm with a previously configured authorization gesture (e.g., fingerprint, faceID, or PIN). Once this is done, the website will respond with a "Registration complete" message. The user will be able to log in to the website from their phone without having to enter a password.

Another scenario is using a registered device to authenticate to a website on the user's laptop or desktop computer. To do so, the user will have to pair their phone with their computer via Bluetooth. Then they navigate to the website from their laptop and initiate login. The user will see a message, "Please complete login on your phone". On their phone, they will see a message prompting them to sign in to the website. When the user selects the prompt, they will see a list of available entities, e.g., "Sign in as Jane Doe." When the user picks an identity, they will be asked to verify their identity with a previously configured gesture (like fingerprint or PIN). Once this is done, the computer will display a message that they are logged in as the chosen identity.

When browsing from computers equipped with a fingerprint reader, the user will be able to register the given computer as an authenticator. Thanks to this, they won't have to use their phone or any other external device to authenticate to the given website.

The use of platform authenticators (authenticators embedded into the device or operating system) and cross-platform authenticators (authenticators used with different devices, like key fobs) can be combined to create high-security scenarios with excellent user experiences. For example, you may want to require your users to use a cross-platform authenticator to register. Perhaps you're presenting employees with a key fob, and you want to ensure that only your employees register on the system. But once they're registered with your company key fob, you might let them add a platform authenticator. Subsequently, they can use their laptop's fingerprint reader to have a frictionless login experience.

A different example is using WebAuthn functionality for authorization of some concrete event. For instance, you could use Web Authentication to allow the user to authorize a single transaction using a security gesture on their device.

Conclusion

Web Authentication is a relatively new specification but is quickly gathering momentum. Since WebAuthn has support (though sometimes limited) on all major browsers, Android, and iOS, it can be adopted safely on production websites.

Apart from allowing users to move away from a password-driven Web, using WebAuthn will also make your systems immune to phishing, a threat that has become a dominant method to steal user credentials.

If you want to try it out using the Curity Identity Server, have a look at this WebAuthn How-to.