 So, yeah, hi everybody, thank you for joining, my name is Maud, I'm a developer on the Chrome security and privacy team and today I'm with my colleague Melissa, who will be following along the workshop and yeah, it's awesome to have you all here today to run the workshop on two factor authentication with a security key, which can actually be a phone. So, yeah, let's dive right in and the workshop, yeah, welcome as I said. So, we can start with a little run through of the agenda. So in the first, thank you, in the first spot of this workshop, this will be mostly an introduction and also we'll be going through some set of steps together or you will be going through some set of steps that are necessary for you to be able to follow the workshop. This will last about 30, 35 minutes and this is an important piece of the workshop. Once you're all set up, we will be able to actually, you know, get hands on and write some code together and to implement what I'll tell you about, so credential registration and two factor authentication. I think this may be about 40 minutes, these are estimates, of course, and then if we have time left, which is not a given, but in case we have time left, we'll try and answer a few questions or look into some code enhancements on top of the basic code we'll have written. And finally, we'll end up with some wrap up and goodbyes and the whole duration of the workshop is expected to be about 90 minutes. We'll have like a little break at the set up point, so at the 35-ish minute mark. Right, so this is our agenda. So we can dive right in and start with the introduction and set up. And in this piece, I will also ask you a few questions, so be ready for that. You will see a poll popping up in a few slides. But first, yeah, let's talk a little bit about what you can expect from this workshop. So what you will learn today, hopefully, at the end of the workshop, is the basics of web authentication. The second thing you will learn is how to implement two factor authentication with a security key or a phone as a security key, which will need to be an Android phone, but we'll talk a little bit more about that in the actual set of steps. And we will also have a chance to cover some best user interface and user experience practices when you're using WebAuthn, which is the API we'll be using today. Now to the things we will not cover, just because 90 minutes is actually not that long time. We will not cover how you can migrate from your current authentication system into WebAuthn. We will not cover how to build a FIDO server. So FIDO stands for Fast Identity Online, and you can think of it as the server that will deal with the really authentication logic for this workshop. And this is actually okay for you to not learn right now today how to build a FIDO server, because in the real application, you would typically also rely on the library for that. So it's fine for us to not dive into the details, but just know that in the real application, you would rely on the library, and as when you typically rely on libraries, you would need to do some due diligence about the quality of this library code and whether this is doing what you actually expect it to do. We will not also dive too deep into account recovery techniques, and we will also not talk about the future of WebAuthn. All of that, you will have a chance to ask questions about these topics in a different channel. I'll come to that, but just so you know what to expect for this workshop today. Right. Quick disclaimer, as I just mentioned, we'll only have time to cover the basics, and you will see that WebAuthn is actually a pretty wide topic potentially. But what we will do is that this workshop you see today first is recorded, so we'll post a link to the recording once that becomes available. And the second thing we'll do is at some point in the future, we will, sometimes soon, we'll be posting a more complete version of this workshop in the written format, so really more like a code tutorial. So we'll be posting that on Twitter from both these accounts. So if this is something you're interested in, make sure to check it out. Right. If you get lines for the workshop, just to make sure that we have time to go through the topics we would like to go through together today. We'll be running through all of the code examples, like all of the code together, in case you're stuck. So in case you're following the workshop steps and something is preventing you from following the workshop properly or going to the next step to encounter an error or anything, please ask your question on the chat and prefix it with the word blocked so that we get a heads up and know you're blocked and can pause and help you resolve your issue to make sure you can follow along. If you have a question or just curious about one piece of code, we just looked at. Also ask your question on the chat, but don't prefix it with blocked. And for these questions that we'll see up in the chat, we'll try and cover these in the end of the workshop if we have time left and otherwise we'll let you know how you can get answers for this. Great. So what are we going to build today? The web application will start with the startup code. It's a little small right now, but it will be very basic. It will be just think of it as a login page with a username and a password. And upon successful login, this will redirect you to an account page, which will initially only display your username and you'll be able to sign out. So the user flow is super basic. You'll just have these two pages index.html and account.html. This is what I've just described. So this is what you'll stop with and what you'll end up with. So what we'll be building together. First, in order to support web authentication with the second factor, what you will need today for this workshop is a credential. I will explain in more detail what this is, but the first thing we'll need is to add a credential management UI. We'll build it into the account page. So this is what you can see here with the two factor authentication possibility to add a credential and this here will display a list of registered credential. Once we'll have that, we'll be able to actually build a more elaborate loading flow that actually enables users that have a credential registered to go through a second authentication step. So once we have that, what you'll be building is that the second two factor authentication page which will prompt the user for a credential, which could be touching their security key or tapping the right button on their phone. So yes, this is what I just mentioned. So if we compare that with the initial user flow for the starter application, you will have this extra step where we will check if the user is set up for two factor authentication. If they are, we will ask them to authenticate with the second factor and if they're not, we will just accept their correct password as a sufficient way to log in. Right. Can maybe pause here just for a second and check if you have any questions on that and if you do, please ask them on the chat or unmute yourself and ask a question. I don't see any question right now. So yeah, feel free to ask if anything is up here at this stage. Great. Cool. Moving on, let's take a quick look at web authentication in short. What is it about? What is this API? Thank you. So web authentication stands for web authentication API and this is really the main API we'll be looking into today and you will see that the API surface itself is a web API but the API surface itself is really simple. It's basically we'll be focusing on two simple calls. I'll come to that when we look at the code. And the idea behind web authentication is that it's the standardized and phishing resistant protocol that can be used in any web application for authentication. This is the quick overview. So how does it work exactly? The way this works is it relies on public cryptography and users creating private public keepers instead of a password. I'll just pause here for a second just to let you know that in this workshop today, we'll be using web authentication for two factors of authentication. There are other use cases for that and our first factor will still remain a password. This doesn't undermine any of the benefits of web authentication but just so you're not surprised, we'll be using both a traditional password and as a second factor, a web authentication credential. Great. So as I mentioned, in case you're not too familiar, the only important thing to remember about public cryptography is that it relies on a private public keeper. So you have a private key that would be stored on a user device security. This is a secret and the public key will be sent to a server for storage. These are the very basics of web authentication and the benefits are twofold first because the public key is nothing secret and is what is stored in the server. It means you have no shared secret between the client and the server and so this makes databases less attractive to attackers. And the second interesting aspect of web authentication is that contrary to passwords, the credentials you create for web authentication are actually scoped to a given site. So what this means is that if you create a credential for a site that example, it cannot be used on evil site, that example. And that means that you cannot use credentials across sites and which is different from passwords and this makes credentials efficient resistance. Good. So these are the benefits for web authentication. As I mentioned, we have two main use cases at the moment and we'll be focusing today on the two factor authentication use case. The great thing about web authentication is although it's a relatively new standard, it is very well supported across all major browsers, so big Chrome, Edge, Firefox and Safari. If you have time at the end of the workshop, I can detail that a little bit more in the sense that the core features of web authentication are very well supported. If you want to go the extra step and have an implementation that is a little more feature proof, you will need to add some code to make sure this is compatible across browsers. But this is more of a detail and the key thing to remember is that process support is really good for web authentication. Before I move on, maybe I can pause here in case we have any question on web authentication right now. If you're shy and don't want to unmute yourself, you can also ask your question in the written form in the chat. Okay. I'll move on. A quick last story about web authentication and then we'll be done with all the talk soon. You have a question from Augustine. How does web authentication work with Zanzibar? Thanks for the question. I don't know the answer to that actually. What I would suggest is because I don't have the answer to that, I'll take the question and as we wrap up the workshop, I'll point you to a place where we'll have a chance to answer your question, namely the Discord server. I'll come to that later. Great. That's it for now. Great. Cool. Quick last story. Maybe you're already familiar with these terms. Maybe not. That's an interesting thing with web authentication. When you're ramping up, there are terms you may need to be learning. So those are like the very basics of what you need to know today in order to follow the workshop. So first important concept is the credential. The credential is the private public key pair. The public part of it is told on the server and the private part is on the authenticator, which is either a software or a hardware that will be generating your credentials and also assert possession of a given credential. So you can think of it as the authenticator is basically either your security key, physical security key if you have one, or it may be a phone. And both a security key and a phone are called roaming authenticator because you can basically use them pretty much with any device you would be trying to log in with. And this is supposed to, so roaming authenticators are the one who focus on today and the other type of authenticator you have are platform authenticators. And these are typically touch ID on a Mac. So these are the ones that are built into a given device. So long story short, authenticator for today is going to be either your security key or your phone. Next term only is the relying party. So the relying party is pretty much the, it's going to need to be your website or your website's server more specifically. It's the party that is relying on a given authenticator in order to help, to have users log in. Right. And finally, FIDO server, again, as I mentioned briefly in the intro, you don't really need to know what FIDO server does in detail, but just remember that this is the type of server that actually takes care of the more lower level authentication logic. Right. If you're clear with these terms, this is pretty much like all what you need for today. So let me just briefly walk you through in detail how the registration, how the flow works for WebOSN. So you have two important pieces to the WebOSN, two factor authentication flow. The first piece is going to be registering a credential. And in order to do that, you can see on the right, the blue is pretty much like the user or the user's device. And on the left, it's going to be the website or the relying party. And the way this would work is in case you want to create a new account, the server is going to ask for a public key, so the public key part of the credential. You will be creating a new key pair via your authenticator and using the WebOSN API and then send the public part of that to the server. This is in order to just create a credential. And then later on, you're going to want to use that credential for actual two factor authentication in our case today. So in order to do that, the server will ask you to sign some specific data that you will be signing with the private key that's on your authenticator, send the signature back to the server who will be verifying it. And if it looks good, it means you are who you say you are and you have successfully been through the second factor authentication step. This will become much clearer once we actually look at some good, but this is just a quick overview. Now before moving on, it would be helpful for us to understand like what's how well do you know WebOSN and how you're set up for this workshop. So for this, I will ask Hayley to launch the poll. So you should see a little window pop-up on the chat interface that's asking you the question number one in a few seconds. Sorry, just a moment. Hayley, are you able to launch the poll? It has been launched. I see people responding. Oh, great. Okay. Awesome. It looks like it's launched. Yes, I had no idea this API existed, so no. So this is great. You'll be learning a lot hopefully today. Yes, exactly. Thanks Chris. So there's a little notification bubble in the corner of your screen. Yes, bottom left icon. Bottom right. Okay, sorry about that. Either bottom right or bottom left or your screen. You should see a little window pop with a question. Okay, right. Polls in the triangle. Okay, sorry. You probably need to click the little triangle square and circle icon before maybe be able to see the poll. So make sure to click that because we have like two more questions. I think we can probably... How many answers do we have? We have a majority. Yeah, okay. So most of you are not familiar with the Webathon API, so this is first, this is good to know. And we can move on to the next question for you, which will be, sorry, I will show here. Have you already set up a security key or phone for this workshop as documented in the set of steps? So, yeah, this has popped up. Great. I'll give you a few seconds to answer that. No worries if not. It's just for us to understand how much time we want to allocate to that today. There's a message here. Sorry, just a sec. Okay, Chris is saying, I did, but it's on a different phone, which I can go grab. Yes, Chris, now is a good moment to grab your phone, which you've already set up. Yes. All right. Cool. Let me check. Cool. I have a bunch of votes here. Okay, so not about half-half, but a bunch of you haven't yet gone through the set of steps. So this is good to know. And the third question we will be asking, so we can move on to the third question for this poll is more of an information. If you don't have an Android phone, or if you don't have a physical security key and you're going to have to use DevTools, it would be useful for us to know if this is your case. So answer yes to that question if you have neither an Android phone or a security key handy. This is your case. No. So I understand right now, looking at the numbers that most of you actually have a security key on Android phone handy. Let's give it a few more moments. Good. So no worries. It's going to work out also with DevTools. I will say, though, that the user interface for DevTools is going to be a little bit different because you can think of DevTools as really an emulator for a physical security key or a phone. And it works out for the purpose of this workshop. But what you will see in your browser is going to look a little bit different. This is not a problem. But just so you know, don't be surprised, I will be using a physical security key. So don't be surprised is if what you see on your screen specifically the native browser popups are probably not going to be shown in the same way for you. So don't be surprised if what you have doesn't look exactly like what I have right now. Good. Great. So where are we now? Setups. So yeah, we're coming close. As we've just seen on the poll, not everybody has had a chance to go through the setup steps. And this is important because you're going to need an authenticator in order to be able to follow this workshop. Either phone security key or DevTools. So the setup steps are not sent for the reminder you made. Okay, this is good to know. Thank you. It's no worries. We have time. We will take some a few minutes now for you to go through the setup steps. So I'll be pasting a link in the code. And this is a link to a worksheet which contains a section called Before the Workshop. And from now we'll give you about 10 minutes to go through the setup steps. So let me paste the link. This is the setup doc. There it is. Great. There you go. Everybody should have access to that document. And actually let me just briefly share what's on there just so you've seen it. This is pretty straightforward. You will have a few steps to go through. And it's going to be important for you to actually test, you know, setup and test whether you're using an Android phone or an actual security key. Or DevTools. Thanks. You're going to have to test it out. And in case you're using DevTools, the most important thing is that you are able to display the little web open panel in your application. But this is all documented. So I think from now on, Hayley, we could like, you know, take 10 minutes and let everybody set up or, you know, grab some water or whatever. Take a good break if you're already set up. And then come back at 40 pass. And hopefully by then everybody is all set up. If you're blocked, ask your questions on the chat and we'll be happy to unlock you. So I think, Hayley, you can, if you're fine, just like playing a little break music. Everybody, we can tell you're good with music. So go ahead and let's continue. The next question, I'm checking out the answer right now. I'm not too sure, but we're checking it out. Hold on for a moment. Phone is a security key. It's not an actual phone. So in that case, either you have a physical security key. In that case, just use that. And if you don't have a physical security key, you're going to have to, on the next, you're going to have to use the DevTools interface. This is also linked in the set of documents. Does that answer the question? Oh yeah, the music is louder now. Can you hear me better now? Hayley, would you be able to pause the music for a second, please? Thank you. Yes, so to the Linux question, right now phone as a security key is not enabled on Linux. So you have two options. If you're on Linux, you can either use a physical security key if you have one. And if you don't have one, you're going to have to use the DevTools interface. Does that answer the question? Great, noted. Thanks. I think we can resume the music. Yeah, you can resume the music. Thanks. So one more minute and then we'll be continuing. So in case you're stuck in the set of steps, please write on the text so we can help you travel. Good. So we're at the 10 minutes mark. I hope everybody was able to follow this set of steps. Again, if you're stuck, now is a good time to post on the chat. All right, Muthu is saying works with a security key but didn't get the notification in the phone. I suspect it's maybe because of a mismatched user account. But I'm thinking if you have it working with the security key, use the security key for the workshop. And then we can later help you travel with that. Awesome. Great. Cool. So yeah, let's continue. Let me check. Few notes. That will be useful for the coding piece. We're entering now the coding parts. Just in case I'll be hasting in a minute in the chat the actual workshop steps. So this is really more of a plan B document in case you're lost on one of the steps and lose track. Because hopefully you should be able to all stay together and just follow me and that should work out. But in case something goes wrong, this document should be helpful. I will be posting it on the chat in a minute. It's actually the same doc as the setup doc. So forget what I said. If you scroll down at the bottom of the setup document, there is something called a section called during the workshop. And this is your helper section in case you're stuck in between two steps. Okay. Mod Akash has a question. Yes. He has registered successfully but not able to log in. Can you give us more info? Let me check. Akash, would you mind giving a little more details like where did you try registering and where were you not able to log in and what are you using? And as you write that, I will continue as you share more information to help you troubleshoot on continue with the workshop steps. Okay. Quick disclaimer, you will see I mentioned the first logging steps here is a password entry. We don't actually check the password in the code just because we don't want to store the password in that demo page. And it's not actually checked for correctness. Obviously, in real application, you would actually check for password correctness. It's kind of nicer. And all right. Let me pause here. Credential operation and code promise. I think could you try, please? This is actually not useful for now. I think this is an error you can ignore for now because I think it's an error in the documentation code lab and it should work fine with Mod's example. Yeah, exactly. So if you got to that step, you're good. Yeah, exactly. If you can see the little web authentication panel showing and if you can click the button that says enable emulator authenticator, for now you're good. If you still encounter issues later, let us know before now this should be fine. Akash, still feel free to share more details about where you're stuck so we can help you troubleshoot. Well, I'll keep on. Second disclaimer, we're only doing in this back end some basic security checks. So we're doing CSRF checks and we're doing some input sanitizing, but there are lots of things that are not in there because it's just a demo. For example, we don't check for retries on the password, which is not checked for correctness anyway, but I guess the takeaway is don't use that code in Prod, right? Finally, in general, it's a good idea for users to have two plus security keys and if you're using your phone, it can act as one security key, but not as several. We're entering here a little bit the realm of account recovery. So it's not too relevant maybe for now, but the summary of that is if you end up implementing web authentication in your application, you want to make sure that people have actually several authenticators or several credentials registered for authenticators. This is more of a side note. Some commands you're going to need for this workshop is how to comment and comment a block of code. This is the same as individual studio code if you're using code. Either a command slash on Mac and control slash on Windows and Linux, I guess. Great. Quick pause here just to help folks troubleshoot. Okay, no more alerts here. So let's continue and an important thing is I'll come to that in a minute and I'll be sharing my screen. Make sure to open your little demo application in a separate window because if you test it out next to your code, there is a behavior that's intended with web authentication, but that will make it so that it's not going to work in your next to the code window. So just open your code in a new window and do it the way I will show you. And I think with that, we are done for the setup and we can actually move on and write some actual code and look at some actual code. Again, if anybody is stuck, you know where to write. So the first thing you're going to do that I've already done actually is you're going to navigate to the starter code which I will paste right now in the chat. So you're going to go there on glitch and you should see in the UI of Glitch, a button that enables you to remix this project. As you can see here, so you will click that button. It's either here or in a you know, in a purple area on the top right of the screen. So you're going to click remix and this will create a new project for you which will have some sort of random name, sometimes glitches a little slow preparing projects. So I'll give you some time here. Yeah, Akash, I think the issue may come from the fact that you don't have the same account potentially on your laptop and phone. So I would suggest either use a security key if you have one because we don't really have time to get into the details of troubleshooting now. So either use a security key if you have one or you're going to use the DevTools UI in order to follow the workshop. Great. Cool. So hopefully at this point everybody should have been able to clone the code. So this is where you should, you know, this is what things should look like for you. As I mentioned, you can see this preview here of the application. Don't use that, close that window already because this will fail. Instead, what you're going to do is open this application in a new window. Sounds good, Akash. Please write if you encounter any other issue. So what this should look like right now is you have your, we have our code here and here on the app open just in the next step the actual deployed application for that code. And sorry, I didn't mention glitches as you've already understood. It's a platform where you can live edit code and it also instantly deploys the code you just edited, which is kind of awesome. So the way this is going to work across the workshop is we're going to do some good edits here and you're going to just reload your page here and the changes are going to be reflected live deployed on the web, which is cool. Right. So hopefully everybody should be there. Let's explore just quickly the code we have here. Today we're going to spend most of our time in this file here, which is called all of that plan that JS and it's basically client site authentication codes. And we will also spend time on our views because we do have some logics on our views. You will see that the code is very vanilla. This is intended. It's just for us to make sure that we just focus on web authentication code. We didn't invent anything special when it comes to rendering. We're using the very basics and just vanilla JavaScript. So we have this file here. Make a note of that because we'll be spending a little bit of time in that file. And we have a few other interesting files. The first one is index.html. This one is the file where this is the html file for this index page to sign up or sign in in the sign in form. You will also notice across the code a little octopus emoji with some step numbers. This will be actually the workshop steps. So just make note of this. Another view file we have here is account.html. So this is the actual account page. And finally we have the second factor page that we're not using right now that will be prompting the user for the second factor. A few other interesting things potentially are Libs. So in the Libs we have all of that JS which is taking care. This is the actual backend code, right? And you will notice that it relies partly. It does use as a dependency the simple web authentication server from FIDO2. So this is a FIDO server implementation I told you about. You can see we're importing it as a dependency. And we will have a chance to look a little bit at the code in there, but probably not make any edits here. And what else do we have? Another potentially interesting one is the server JS again for this workshop will not make too many, will not make any edits actually into this file. But just highlighting here that in here you can find authentication logic that you may be already familiar with. We're checking for a quick expiration. We're making sure that the user can only access the account page if they're actually properly authenticated and so on. So this behavior is not magic. It's just already kind of here in this boilerplate code. Great. Quick pause here. Great. I don't see any questions. So as long as we don't see anything in the chat we'll continue with the workshop. So let's actually get started. So the first thing we're going to do is as you can see right now I can have, whoops, I'm going to just play around a little bit and create a dummy account. So that's all we have right now. So the first thing we want to do is actually enable the user to create a credential which can be used for factor authentication. In order to do that the very first thing we're going to do is to create a utility function in our client side authentication file. So I'm going to go to the first thing you're going to do is go to auth.client.js and if you go to line 49, if you scroll down a little bit, you will find something called step two. Step one was just working the code so you've already done that. And this is step two. We will end comment that code, right? So I'm using the comment slash comment here. And what we've just done here, we've just implemented the code to actually register credential. This is just utility code. So the most important code in there, we're doing a few things here just working through the steps. The first thing we're doing is we're actually fetching some credential creation options from the server. I'll come to that in a minute. We'll look at what these are. But this is important to have in mind that when you're registering a credential, you are going to first ask for the server for some credential creation options. You're going to have to decode these options because they come in and code it. Here, again, this is not a web API. This is actually code that we've imported from a helper file here. We have encoding.js. This is our just utility function to do the encoding decoding because it's not the most interesting when it comes to Web open. But keep in mind that these options will come back and code it. So we're going to have to decode them. And then you're going to, this is the most important call here. It's a navigator that credential that creates. So you can recognize here that this is a Web API. And upon calling that with credential creation options as a parameter, what will happen is that the browser will prompt the user to touch their security key or, you know, tap the right button on their phone. Oh, please don't edit that code. Sorry. I'll, okay, sorry, just sorry. I'll, like, remove rights. You can still see that code, but don't edit it. Yeah, so this is the most important call. This will actually prompt the user to touch their security key or phone. And then once you've made that call successfully, you end up with a credential. And what you will do is send it back and code it to the backend, which you can do, which you can see here. Right. So let me check. I would like to briefly maybe take a look with you at the credential creation options. Like what is that about? So let us check. Actually, I should do that here. Sorry. Let's look at our credential creation options. Sorry, just a moment. Step two. Step two. Right. This is the code I wanted to uncomment here. This is what we just done. And before we move on, let's just briefly look at our credential creation options. Just so you know what this is about. Let me check. So we're getting this from our backend. The reason I just want to tell you a little bit about this, because this is, or you can think of this as the security settings for your, for your application. So whatever I will show you now may, you know, you may want to tweak that depending on your security model and what kind of credentials you want to ask for. But basically, I'll walk you through a few other interesting options in there. So the credential creation options are, you have several of these. The first one is the relying party ID. So this is really like the name of your application. And if you remember, we said that credentials were scoped to a certain origin. This is what makes them a phishing resistance. And this is why the relying party name and ID are, this is how they're used. Right? So here the RP ID is going to be the host name. So in my case, you know, it's going to be narrow, mangrove train that glitched at me, and whatever, whatever your forked application name is, this will be the RP, the relying party ID for you. Other interesting things are for your security settings around the, you know, what kind of as indicator you want to allow. One of them that's interesting is user verification. So right now for this workshop, we only have basic security keys that only requires, you know, you to touch them. You may want to have more, you know, stronger security and actually ask for a biometric security keys. And in that case, you would change, you would change this very setting. I'm kind of running through them here because like the best thing is to, you know, check them in detail and check the documentation. But the key thing is for you to understand that these authenticator selection options are how much security like what do you want to, what kind of authenticators do you want to allow and what kind of credentials you want to allow for your application. Let me check if this one is interesting. Yeah, this one is interesting. So for this workshop, we said we would be using roaming keys. So either secure physical security keys or a phone. So this translates in the web of an API as something that's called cross platform because you can use them across platforms. If you wanted to instead have built in built in authenticator, you would need to set that to something else. There are a bunch of other interesting ones, but I will just like go a little quicker here. The only last thing I want to kind of show you here in the credential options is here we're coming into the UX and UI best practices. So you want to encourage folks to only register per security key only one credential because otherwise the UI to select a given credential for a security key is complicated. So basically, this is what this allows. Here we're telling a one credential creation. I don't want my user to be able to create a credential on the security key where they already have a credential for my application. And this way you ensure that you only have your users only have one credential per security key. Yeah, there are a bunch of other interesting options. But for now, this is it. So all we've done so far is just we've, you know, and commented a piece of code on the on the of that client. So that was step two. We're not using that function at all for now. So let's go ahead and actually use it. Right. So what we're going to do now is we're going to go to a counted HTML. And the first thing you will do is you will look at line 45. And you will see that there is some commented out here HTML codes. That is just basically a button that says add a credential. So the first thing you will do is you will comment this out. Okay. So, so far so good. Well, all we do is have we have a button that does nothing right now, right? So the next step we want to do is actually hook that button to the credential registration function we have created. So for that, you're going to stay in the account that is changing file and declare a function that's register, which is already called upon the registration button click like this guy here. So we'll just comment it out. So let me do that. This is a step four. So please and comment everything that is on there. And we'll talk about what this does in a minute. If you like formatted code, you can click the format file button English. So yeah, here's what this does. Yeah, it basically just adds a event click event handler to the register button. And it calls the register credential function we have created. Cool. So let's see if it works out. So go over to the, to your deployed application, you can reload it. And now you're going to, I'm going to open DevTools to see if, you know, everything goes well. Let's check. Great. I'm going to click the button at a credential. And here you can see that I am prompted to select in between these two methods, depending on what you ended up using. This may look a little bit different for you. I think it also depends on the platform you're on. I think on windows, this may look a little bit different. But the important thing is that you as a user, you should be prompted at that moment in time to perform an action that will create a credential. So I'm going to select USB security key because this is what I'm using. And now it's asking me to touch my security key. It's already plugged in for me. So I'm going to go ahead and just touch it. And nothing happens. I can only trust that the credential has been created. We'll come to that in a moment. Something happened, but like I can't see my credentials. And we would like to see our credentials displayed, right? So what you're going to do next is briefly un-comments a piece of code that is dedicated to displaying available credentials for that user. So in account that HTML, you will see Octopus step 5, so line 140. So you can uncomment all the code that is between this line 140 and 940, 54. Cool. So we have that function available now. And now what we want to do is actually call it to make sure our credentials are displayed. So you will scroll up and do two things. The first thing is you will actually call this update credential dysfunction at the end of register, basically after a successful try catch. And the second thing is we also want to display our credentials, available credentials on page load. So we'll just call that function once on page load. So for that, you can uncomment the code that is on 967. Now that we've done that, hopefully, yes. So it automatically reloaded the page, by the way. Glitch does that when you update your code. So you can see that it actually fetched available credentials for me. So it is displaying the credential we've just created. Now let me pause here for a second and ask you folks if this is working out for you. Were you able to create a credential successfully and can you see your credential being displayed? Or rather, say something if it's not the case. Yes, I have a yes. Love it. Good. Yes, that sounds good. Thumbs up. Awesome. Don't be shy if you're stuck. Works. Good. Woohoo, it works. Yeah, Nathan. I'm just as happy as you are. Cool. Cool. Good. Good. So it's looking pretty good, at least for those of you who posted on the chat. It works for me as well. It works for me as well. So very good. Maybe it's time to show the DevTools. Yeah, maybe it's time to show the DevTools. So that sounds good. I'll try and show you how it works with the DevTools option. So the first thing I need to do actually was I probably should have, ah, WebAuthn. So I already have this tab here. And if you don't have it, go to More Options. Yeah, let me find more tools and then WebAuthn. Thank you. So three dots at the top. Exactly. The three dots. Thank you. So if you don't see that, whoops. I think the other three dots at the top right. Oh yeah. Okay. Cool. So here, thank you. More tools. And here you have WebAuthn. Whoops. More tools, WebAuthn. And I even think if you do Command Shift P, you can look for WebAuthn. This is the same shortcut as in code. But so three dots. More tools, WebAuthn. Everybody, if you're not using the DevTools panel, just bear with us for a second. We just want to show how it works for those of you who are using DevTools. So sip your water and just hold on for a second. I'm going to enable the virtual Authenticator environments. And I'm going to add a new Authenticator. This is a little bit like if I was buying a new security key, right? So I'm going to do that, right? Then no credentials were created. So what I'm going to do is click the button again and see how it goes when I create a credential. Yeah. So you can see something happened here. DevTools knows that, oh, you have this virtual Authenticator. Georgia, yes. Good to know that you had to reload. If anybody is encountering an error, you can reload. So here you can see that this was actually, this is also successful with DevTools. You can see here your credential pop up and hopefully it also shows up here. Another thing is we're not showing the code for that, but it's kind of convenient. You want your users. This is the best practice for UX. You want your users to be able to remove the credentials they've created because maybe they've lost their security key or just they're using another one. So I won't show the code for that, but you can check it out in the code later. I'm going to go and remove that just to start on a clean state. Cool. Another interesting thing I'll show. So that was for DevTools. DevTools parenthesis closed. I think we've showed the basics. Great. So we can... If you don't want to have issues, now's the time to speak. Yeah, exactly. As always. And now what we're going to do, I'm going to keep on with my security key now. So I'm going to add a credential again. Great. Something interesting will happen. I'm just going to show you briefly what happens. Try it out also. What happens if you try adding a credential again? It's going to throw you an error. It's going to say, hey, the user attempted to register an authenticator that contains one of the credentials already registered. If you remember, in the previous step, we had this thing called exclude credentials. So this behavior actually is intentional for us. We don't want users to be able to register two credentials for the same authenticator. So this is work as intended. Obviously, like in the application, you would deal with errors in a nicer way because this is, oh, you cannot see the... Oh, interesting. So you cannot see the browser pop-ups, right? Okay. So I will describe to you what I see. I can see like a native browser window pop-up and telling me that there was an error. You cannot see it on the screen share apparently right now. But if you try it out on your side, you should see something similar. Great. All right. Let's move on. So what do we have now? Okay. We have been able to create a credential. What we will do now is what we're displaying right now is the credential ID, which honestly is ugly, right? And it's also not human readable. It's difficult for people to read something like that. So what we would like to do instead is enable people to give credentials names, which are things humans are better at as long strings. So what we will do next is go to account.html. And this is step seven. You're going to go to line 115 and you can encode all of the codes between line 115 and 137. Nothing about breaking. We're just taking that the name is right. The only interesting piece here, because like this is code you probably already know how to write, the interesting thing here is I will show you in the auth.js. Is that by default, the web of an API doesn't support naming credentials. So this is something you will have to set up yourself. So you're just going to have to add in your backend server just a new field for name, not username, but say check. Yeah, probably that. So this is about credential creation. We're making it an empty name, which is why you can only see a name tier. But the bottom line is like, this is not included in the credential and this is not part of the native API. You will have to this is the best practice for your users to actually enable them to name credentials. And also to rename them. So today in this workshop, we will not show that, but make sure that you also enable people to rename their credentials. They made a typo or whatever. So where were we? We were here. We were on step seven where we just uncommented the rename function. So I'm going to go back to account that is GML. And then we need to actually use that function because we're not using it right now. So what you can do is copy the code that is between lines 99 and 102. So you are going to copy that. And you will replace what is on line seven and seven by that new code, which does the same, but it also calls a rename upon successful registration. So you just first create a credential and then rename it. Don't know rules. You could also ask for a name before credential creation or just rename it after the credential creation has been successful. The web author and spec is not, you know, doesn't say anything, doesn't give specific directions about that. You can do one or the other. They propose both. So right. So we have now renamed function and we're enabling the user to actually rename the credential that just created. So let's see how that behaves. I'm going to remove that credential just to show you what happens when I create a new one. Feel free to do the same. And add a new credential. Again, apparently you cannot see my, like the native browser window pop up on my screen. What I see right now is a browser window asking me to name this credential. Hopefully you should be able to see the same. So give it whatever name, cool, like small security, for example, or whatever. So I'm going to give you a name. And as you can see, I know how to name credential. Code wise, this is nothing where I'm ranking, but it's just to show you that it's a good idea to enable users to name credentials. And then it's kind of up to you whether you want to display the credential idea or not. If you do, it may be good idea to ellipse, you know, that basically move away the middle content. Because like it's just a long string and it's still recognizable if you dot, dot, dot instead of this long string. But it's important just to have a name. Let me briefly pause here. And ask if anybody has a question or is stuck. Were you folks able to, you know, register credentials and rename them, name them? Augustine, make sure please that you are going through the steps in a new tab, not within glitch. Because the error you just pasted, I saw it when I was trying to make the registration happen within, within glitch. So don't use, don't use, you know, what is it called? Yeah. Don't like, don't do your user interaction in this, in this part, just really like open it in a new window. And if you do that, hopefully this error should go away. Stefano, yeah, it works great. So Augustine, please try this out and let us know if it worked. Chris, interesting, just an observation that the idea is infinitely shorter for the USB key than a phone. Good observation. I didn't have that in mind actually for today. So this is good to know. Thank you for sharing. Definitely something to keep in mind for the UI too, actually, right? Yeah. Cool. So we see yeses, right? We'll keep it on the chat. I'm sure it works for all. Yeah, it works for you. It works for me, so. Okay. Cool. Let's continue then. We are a little short on time, but all good because we're basically done with the first part. The most important thing is enabling users to create credentials. So I'll try and go through the next steps a little quicker. And now that we have our credentials, this is cool, but if I sign out as Bob right now, we don't have yet this thing where I'm actually asked for my credential for my second factor. Actually, this kind of breaks altogether, because the code is wired up so that here, because I have a second factor set up, I'm expected to enter a second factor and touch my credential and give it my credential. But right now, we haven't done the UI wiring to actually ask the user for a second factor. So this is going to be just not working. So let's do it now. Moving on to actually implementing the second factor authentication. This should be much lighter than the first part. So let's go ahead. You're going now to go to public of client.js, you know, or buy for utility functions for authentication. And you can uncomment the lines 85 to 95. This is our step nine. Here, we don't have time to go too much into the details, but we're like fetching options from server. And the most important call here is a navigator that creation that gets. When this is called the browser, when you call that, what will happen is that the browser will actually prompt again, the user to touch their security key or touch the right button on their phone. And once you do that, you know, the code will get like a credential out of that. And we'll be able to send this credential to the server for verification. So we've uncommented that. Again, it's just a utility function that we're exporting. So awesome. So right now what we need to do is go and actually use it. So what we will do is first go to index.html. So what we will do here is we want to make sure that when the user actually has a second factor registered, they are redirected to a second factor authentication page. So as you can see right now, we are not doing that. So what you can do is you can uncomment the lines 105 until 111. And you will see that what this does is it checks if what the authentication status is. The authentication status is just an object we're keeping track of in the back end. This is like a session tracker to check what is your authentication setup like. If it's complete, it means that if you only have one factor set up, your password was correct. But if you have two factor set up, authentication status is only complete if the second factor also has been entered. Again, the best thing if you're interested in that is go and check the code later. But the most important thing is if you need a second factor, what we're going to do is redirect you to the second factor page. Great. And then, just a moment, sorry. Yeah, okay, that's an important one. Okay, we'll look at that in a minute. So back to index.html. Now, let's see what this gives us. Let's briefly check. So let me just check it out. So I'm Bob. Try it out also on your site. Chris, I'll get to your question in a second. First try out the code you just added. So now we know that Bob has a credential registered. So normally, he should redirect me to the second factor page, which it does, it's good. But at the moment, we are not actually using our second factor authentication code. So if you click that button, it does nothing, which is not what we want. So we'll fix this in a second. But make sure that the behavior is right and that you are able to see the second factor authentication page. Great. Quick pause here just to get to Chris's question. Chris, I say it's not a blocking question. Let's get back to it in the end. Moving on. This is actually the last step, I think. Yes. What we're going to do now is go over to second factor.html. And what you will do is end comments all the codes that's between 54 and 69. So end comment all of that. Let's talk briefly about what it does. The first interesting thing is it actually calls our utility function that we have just implemented in Authentication.js. You know the one that actually makes the navigator credential that get call. So this is the first interesting thing. And then it's going to look at the authentication status and the response and check if it's actually complete, which would mean that authentication was successful. There's an important piece that we haven't really talked about, but that I would love to show you now is look at what actually happens, what happens in the back end when we do that. How is verification taking place, right? How do you know that the user's credential has been, is correct. So that's, they can briefly get that. I think if we look at, yes, that's where we were already. So if you look at in Authentication.js, or you can just look at my screen if it's easier, because we don't, we're not going to edit any code here. The most important call here is this verification call. So here we're relying on our FIDO2 server implementation, which is our library. And we're calling this function that for that library, they call verify assertion response. And this is really just like credential correctness, a credential validity verification. So you give a number of parameters in. One is the credential, of course. But there's also a challenge aspect that I don't really have time to explain, but you can think of it as a, the challenge is useful to protect from a credential theft in the, in the sense that you always want to check just in time that the person, the credential you just received was actually sent to you from a person who actually owns the private key and has been basically signing this challenge on the flight at the moment in time when you requested it. This is a little quick, all of that in the documentation. So if you're, if you're curious about that, you can read up. You also have a bunch of other things like the expected origin. As we mentioned, credentials or scope to specific origin. So this is going to be checked and more, but this is an important bit. Right. So this is what happens under the goods. So if we're going back to second factor, this was step 11, which is actually our last step. So now hopefully our second factor page actually does something and upon upon user navigation to this page will actually be able to prompt the user for their credential. So let me reload that page. Do it also from your side, try it out. So log in as the same user as before, the one that had a credential. Click next. And here we have this button where you know, you're going to have to tap it to use a security key. Oh yeah, it's using their tools. Sorry, let me disable the virtual authentication environment. Just a moment. I'm going to create a new credential just because I had both DevTools and a security key and this messed up things a little bit. So let me try again. This is still buffed. I'm going to enter my password. I'll be prompted. So I'm going to tap this button. And I'm going to pick security. I just touched it. And now was able to successfully log in. Hopefully you should see the same thing going on for you. Yes. So Chris, your question was moved. Okay, noted. Yes. Can everybody, was everybody able to go through these steps? Yes. Great. It works. It works. Yep. Awesome. A request is already pending. Muto, I have not seen that error before. I would try, you know, just like hard reloading the page and like signing out and trying to sign in again. I'm not sure what this is about. Okay. Sounds good. Cool. Working out for everybody. Anybody stuck? It works for my side. Good. Works on my machine, right? Okay, cool. It's good because we're actually coming close the end of our workshop if I'm not wrong about that. Five more minutes. Five more minutes. Cool. So hard reloads work. Always does, right? Good. So we are actually done with the very basics of WebOSN. So this is good. Yeah, congrats, everyone. Yeah, congrats, everybody. Well done. Let's take a few moments to wrap up. There's your changes. Giorgio, time now, always not allowed. Unfortunately, we don't have time right now to go to the first test, but I understand Giorgio worked for you the second. Yes. Okay. Awesome. So of course, we didn't have time for the extra things. Good to know. Thanks, Giorgio. So let's wrap up. We have a few more minutes. So let's wrap up. Great. Thank you. Good to hear. If you want to learn more about that, this was really just a very basic. So if you want to learn more about that, please follow like from there or me on Twitter, because we'll be soon posting a first written and more advanced tutorial version of this code lab soon means, you know, in the next weeks at some points. So it will contain your more detailed explanation about, for example, the credential creation options and like all of this other stuff. And this workshop is recorded. So we'll also be posting the recording. But for you, it would be more like a repeat. So maybe less interesting. If you have a question about WebAuthn, ask it on Discord. We have a Discord channel that is specifically for Chrome developer summits. We'll be posting the link on the chat. Do you mind posting the link? Yes, of course. I have it right here. Awesome. And I'm there to answer any questions. Yeah. We did size in there. We're in there. So please ask your WebAuthn questions. Thank you. And it's awesome. So join us on Discord. We have a dedicated channel for security and privacy. So join us there. And yeah, thanks so much, everybody for joining. It was it was really cool to see everybody logging in from different parts of the world. Yes, it was a very fun workshop. Yeah. Yeah. Thank you. Thanks, everybody. Stick around for a CDS. It's always good to see you. And yeah, we're in Dutch. And we'll see you around, everybody. Thank you. Bye. See you. Bye.