With the promotion of WebAuthn to an official web standard, it’s only a matter of time before software developers begin to take advantage of its perks. If you aren’t sure of the benefits of the technology, I highly recommend reading my previous post. In short, I expect WebAuthn to have a significant impact on the problem of passwords and should drive websites to multi-factor authentication. This should, in turn, have a significant impact on the number of data breaches and hopefully make everyone’s online experience much safer.
If you are using passwords in your authentication subsystem, I strongly encourage you to take a look to see if WebAuthn will meet your requirements. The specification is quite readable. But if you’re like me, reading specs is a laborious task. Hopefully, this post will help you understand the basics of the WebAuthn specification.
Let’s Start With The Key Players
Like any specification, the WebAuthn spec is littered with terminology, much of which is specific to the document. The terminology is foundational to the spec, so it is incredibly important to have a firm grasp before trying to understand the spec.
A picture is worth a thousand words. I’ve cobbled together an image denoting the key players and their interactions with each other:
There is a lot going on in the image above, so let me break things down a bit.
WebAuthn revolves around the need for a web application to authenticate a user. We call the combination of this web application and its backend web server the Relying Party.
A user navigates to and utilizes the web application via a client. A client is nothing more than a user agent, which is typically a web browser, such as Chrome, Firefox, Opera, or Edge. I didn’t include Safari in this list, because as of today, it only supports the WebAuthn API as an experimental feature.
The client runs on a client device, which is a piece of hardware with an OS. This is typically a laptop, workstation, or even a smart phone. The client and the client device together make up the client platform.
A client device is bound to one or more authenticators. An authenticator is something that has the capability to authenticate the user to the web application. The web application won’t work with an authenticator directly, but will actually communicate with it through the client using the WebAuthn API.
There are two types of authenticators: platform authenticators and roaming authenticators. Platform authenticators are built into the client device. For example, most modern smart phones have built-in fingerprint scanners. There are also a growing number of laptops beginning to integrate fingerprint scanners. Roaming authenticators are external to the client device, but connected to it via USB, Bluetooth, or NFC. Examples of these are USB security key fobs and external smart card readers. A smart phone can even be a roaming authenticator to a desktop or laptop.
The client, client device, and all authenticators make up the client-side.
How Authentication Works
Now that you have a familiarity with the key players in the WebAuthn specification, let’s take a look at how a web application would authenticate an end user.
A user will navigate to a website using a client, such as Chrome, using his primary device, such as his laptop. The user then attempts to login.
The Relying Party backend server will respond with the web application and a secure, randomly generated number called a challenge. The server delivers the web application to the user’s client. It contains a JavaScript payload that, when executed, invokes the WebAuthn API in order to authenticate the user.
The client marshals the call to authenticate the user to an authenticator. This call will include the challenge provided by the backend server. The call will also include an identifier constructed by the web application that uniquely identifies the Relying Party, called the Relying Party ID. This ID contains the domain of the website and a few other tidbits of information.
The authenticator receives the call and uses the provided information to authenticate the user. The user interacts with the authenticator by providing a PIN, fingerprint scan, or the like. This interaction is called an authorization gesture, the result of which is a digitally signed response that is marshaled back to the client.
The client returns the authentication response to the Relying Party backend server. The backend server receives the authentication response, which includes the originally issued challenge and the identity of the authenticated user (called the credential ID). The server then attests the validity of the authenticator utilizes the response’s digital signature (a process called attestation). If attestation was successful, the user is now authenticated.
Overall, the authentication flow is relatively simple compared to many other authentication protocols. WebAuthn also contains a registration flow, but it is incredibly similar to the above steps.
There is very little that you have to do as a developer to harness WebAuthn. The result is consistency for your end users, the removal of passwords from your system, free multi-factor authentication, and a more secure system. In a future post, I will show you how to use the WebAuthn API to register and authenticate an end user.
