 Did you know that there's a browser-based API that enables users to log in without a password? Using device biometrics like Mac Touch ID or iPhone Face ID or using some type of roaming authenticator like a UB key. And that API is called the Web Authentication API or Web Authent for short. And in this video, we're going to learn how the different pieces of the Web Authent API works. My name is Will and I'm here to help you learn identity and security on the web. Web Authent is a browser-based API that allows the creation and usage of authentication credentials that are based on public key cryptography. This can be used for passwordless authentication or second-factor authentication without the use of text message. Web Authent allows users to authenticate using one of two options. There's the roaming authenticators like UB keys. There's also platform authenticators like the matchbook touch bar, the Windows Hello, the iOS Face ID and Touch ID as well as the Android fingerprint recognition. These platform authenticators are a part of the device and can only be used with that device. All right, next let's talk about some of the benefits of using Web Authent. The credentials in the private key are actually stored on the device itself. So there will be no reason for someone to attack the database because there aren't any credentials stored there. It also helps mitigate phishing attempts because you have to make the connection between the website and as well as the authenticator. So if you happen to click a link and try to authenticate with the false website, the authentication won't go through because there isn't a relationship established between the malicious site and your authenticator. It reduces the impact of data breaches. As a developer, you don't have to hash the public key. And if the attacker gets access to the public key that's used to verify the authentication, it can authenticate because it also needs the private key. Users often reuse passwords. So if an attacker gets access to one password, then they have access to a bunch of different websites that have the same user credentials. All right, so let's now talk about the actual Web Authent API. Web Authent actually extends the credentials management API. The Web Authent API has two main calls navigator.credentials.create and navigator.credentials.get. You decide which one of these calls that you use based on which ceremony that you're performing within the Web Authent API. A ceremony is a group of operations performed in a certain way by a group of entities according to protocols and procedures. So the first ceremony we're going to talk about is registration. Registration makes the authenticator create a new set of public key credentials that can be used to sign the challenge that is generated by the relying party. And we'll get into the challenge and the relying party a little later for us what those are. So if you want to set up registration, we will use the navigator.credentials.create function. All right, so when you call navigator.credentials.create, you will pass in a public key object. The public key object describes the options for creating the Web Authent credential. So the first thing you can pass in is the challenge. The challenge is a large, random number used for registration and is thrown away later and is only valid for one transaction. The next property that you can pass into the public key object is RP. This is an object that is describing the relying party which requested the credential creation. So the relying party is the entity that makes use of the Web Authentication. Then to create a user. So this could be off zero Facebook or Google. The next property that you can pass into publicly is user. User is an object describing the user account for which the credential is generated. The ID property is not meant to be human readable and should not contain any identifying information such as an email address. The next property that you can pass in is pub key cred parameters. So public key credential parameters. It's an array that specifies the features of the credential, including its type and the algorithm used for its cryptographic signature operations. You can also pass in timeout which is the time in milliseconds that the call is willing to wait for the call to actually complete. And next is the authenticator selection. And this lets you specify the authenticator requirements. So for user verification, the default value is preferred, and you can also set it to discouraged or required. Navigator credentials.create actually returns a public key credential object that includes the public key as well as other attributes that will verify the registration process. And then once the public key credential object is obtained, it can be sent to the server to be validated. According to the Ubico developer docs, user verification is not recommended for a multi factor authentication and more for password list type scenario. So now let's talk about the second ceremony in WebAuthn, which is called authentication. Authentication allows the relying party to send a challenge to the authenticator. This challenge can be signed with the previously generated public key credentials and sent back to the relying party. So when the authentication ceremony, we'll use the navigator credentials.get function. So when we're using navigator credentials.get, we still pass in the public key object. And we also still pass in the challenge, which again is a random number generated from the relying party. But with navigator credentials.get will pass in something different, which is the property of allow credentials. Allow credentials is a list of public key credentials that are acceptable to the relying party. Credentials can be omitted in a username list authentication scenario. So the navigator credentials.get functions also returns a public key credential object, although it is different from the one that we received in registration. One difference is that it includes a signature member, but does not include the public key. After the authentication data has been fully validated, the signature is verified using the public key that was stored in the database during registration. So that was a developer's overview of the web authentication API. So if you watched all of that and thought that that was way too many steps and kind of thought that maybe it's too much that you want to deal with at this time to add password lists, biometrics to your application. The good thing is is that off zero makes it really easy to turn on biometrics in your off zero account with literally just one click of a button. So that way you can reduce the amount of friction that your users has and increase their security at the same time. Thank you so much for watching this video and let me know down in the comments if you are looking forward to a future without passwords just as much as I am until next time. See you later.