Web Authentication APIs

WebAuthn Workflows

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Web Authentication APIs

Check out a free preview of the full Web Authentication APIs course

The "WebAuthn Workflows" Lesson is part of the full, Web Authentication APIs course featured in this preview video. Here's what you'd learn in this lesson:

Max walks through the two WebAuthn workflows: Registration and Authentication. When a user logs in with WebAuthn from a relying party, an authenticator like FaceID or a USB key passes the user's public key to the server for authentication.


Transcript from the "WebAuthn Workflows" Lesson

>> Well, this is the original diagram of how web authentication works. So it can be you have a relying party, and who is the relying party? We are, our server, our backend is the relying party, okay, the relying party. So then the relying party talks with the client, the client is the browser, using the WebAuthn API.

So this is one of the diagram from Yubico, the one of the keys. By the way, Yubico, the keys manufacturer, is one of the original editors of the FIDO2 alliance that created this API. The relying party, okay, is one of these non-common words here in the web world.

Who is the relying party? Well, we are, our backend is the relying party. So every time you read about relying party, that's the backend, okay? And the relying party is requesting somehow or with the help of the client, okay, that it's the browser. But you can see this application as well, because WebAuthn is also available for native apps.

Even if it's web, it's available for native apps. Because it's not just client base, it's actually a solution that relies on the relying party. It needs the backend, so we need to do something special in the backend so it will work. And then the client or the platform can use an internal authenticator or it can use an external authenticator.

So it can be a USB key or it can be like your finger or your face. And by the way, by external, typically you will see a USB key as an example, but it can be a phone as well. Some of you ask this morning what happens with passkeys, we were talking about passkeys.

And by the way, spoiler, passkeys are based on web authentication. So how can I log in on Windows if I have my passkey saved in iOS? Well, through a QR code on Bluetooth, both platforms will connect. In that case, your phone will act as an external authenticator, okay?

So it's not always a USB key, it can be a phone that will provide the authentication for web authentication. And typically, let me show you this first, and then I go back to the dialog. Web authentication has two flows. Registration, so you register a web authentication, or you authenticate, that is going to be the login.

And both are kind of very similar in terms of the flow. The flow, so what happens in terms of data coming from where to where? It's the same. We change a little bit the code that we write on each flow, but then the process is similar, and this is the process, okay?

First, we are the user. The user goes to a relying in party, so that is the user loads a website, okay? So the website has login with web authentication, okay? So there is a button or something that triggers login with web authentication. So the user chooses to log in without password, that's kind of the idea, okay, or register an account.

In that moment, okay, we go to step number 3, that is this one. The website asks the authenticator to use a key pair, which it starts to sounds really weird. Okay, so the website asks the authenticator. Who is the authenticator? It can be the platform authenticator or it can be the USB key, an external authenticator.

So you ask the API, okay? The thing is that there is a process here going on that is like a double step process. So the client, the frontend will ask the server for a challenge. The challenge is, let's say I'm simplifying the concept, but the challenge, it's a network challenge.

Let's say it's like a math operation, okay? So our backend is going to create the challenge and it's going to sign the challenge. Because we are talking about private keys and public keys here when we are talking about web authentication. With that challenge, the authenticator will ask the user to use a gesture to authorize a key.

It can create a key or it can use a key. It depends if we are registering or we are authenticating the user. So that means the user will receive a dialog, a pop-up saying, hey, put your face here, put your finger, put your USB key. And if you authorize the operation, okay, actually, the browser will sign that challenge that the server sent and it's going to send everything to the backend.

We will send everything to the backend, and the backend will verify, will decrypt that packet and see if the challenge is correct. So I know that maybe you're not following me because it's okay, but it's simpler. The idea is simple. The server will generate data and it will sign the data.

It goes to the authenticator. The authenticator will ask the user to authenticate somehow, with the face, okay? If the user is granted, I mean, the face is the user's face or the finger is user's finger, then what will happen is that the authenticator will take that challenge and will resolve the challenge.

And it will send the public key, the user's public key, that goes back to the server. And the server will actually open that package, will decrypt the package. And it will verify that the authenticator is who he's saying it is, or it's saying it is and that the challenge was resolved, just, Trust that this was created by security companies and they tried to solve all the possible security issues, okay?

So I know at this point, you still don't understand exactly the process, but now we will write the code, okay? And we will see it in action. And then you will understand this double process thing that happens with web authentication, okay? Both for registration and login, okay? I don't even wanna show you the original web authentication flows, because they are so complex to actually follow.

I mean, as web developers, we're not interested in so much detail. We wanna use the API, and we wanna understand what goes on the server, what goes on the client, in which order, what do we need to say? And actually, that's all we care. So we understand the process, and that's all.

But even if the term is web, WebAuthn, the spec, the part that we care about is only the relying party section. That is actually the smallest one, fortunately. All the rest of the spec defines flows and information for platform authenticators. So for whoever is doing the browser or for OS developers, not for us, okay?

So that's why when you go to web authentication, for example, there are a couple of websites where you can read more about web authentication that are open. One is webauthn.guide, for example. When you look at here, you have registration, here, you have some code, okay? But when you look at that, sometimes when you read this, they have a lot of information that is not so important for us at one point, okay?

We will follow the information flow.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now