deepu-sasidharan

Deepu is a polyglot developer, Java Champion, and OSS aficionado. He mainly works with Java, JS, Rust, and Golang. He co-leads JHipster and created the JDL Studio and KDash. He's a Staff Developer Advocate at Okta. He is also an international speaker and a published author.

Staff Developer Advocate

Deepu K Sasidharan

Passkeys and WebAuthn for developers. Learn how passkeys work and the benefits they provide.

A Passwordless Future: Passkeys for Developers

Passkeys and WebAuthn for Java developers. Learn how to get started with passkeys for your Java and Spring Boot applications.

A Passwordless Future: Passkeys for Java Developers

Pradheepa Pullanieswaran

Pradheepa Pullanieswaran is a Developer Advocate at Okta, with a real love for backend and open-source technologies. She has worked in enterprise and web technologies for over a decade and now on the journey of helping developers to better secure their application. She is also an active member of Women Who Code and mentors women to step into the software industry. She loves to read and spends time with her family in her spare time.

Web Authentication API (WebAuthn) is a W3C and FIDO specification that allows registration and authentication of users using public key cryptography instead of a password.

## Introduction

WebAuthn (Web Authentication) is an API specification by W3C that facilitates a secure way for users to log in to online services and websites using various authentication methods, such as biometrics (e.g., fingerprint or facial recognition) and hardware-based authenticators (e.g., USB or NFC tokens). 

## Key Features of WebAuthn

### Phishing resistant

WebAuthn uses [public key cryptography](https://auth0.com/blog/how-to-explain-public-key-cryptography-digital-signatures-to-anyone/); the user's private key never leaves their device. Since WebAuthn relies on cryptographic keys, it is resistant to phishing attacks. Assuming that a bad actor tricks the user into entering their credentials on a phishing site, the attacker cannot use those credentials because they are scoped to a specific domain. In short, a credential created for `webauthn.me` cannot be used by a fake website, `webauth.me`. According to [Verizon DBIR 2023](https://www.verizon.com/business/resources/reports/2023-data-breach-investigations-report-dbir.pdf), Phishing is one of the major attacks on a web-based application, as shown in the following image. Using WebAuthn, the web applications could have easily averted these attacks. 
   
#### Action varieties in Social Engineering incidents

![Action varieties in Social Engineering incidents](https://images.ctfassets.net/23aumh6u8s0i/EAHiNaQrRaclMm2OnR1TA/cc50a06eef6af456d6a02f74731d4f6e/Phishing_DBIR.png)
 
### High-Security standards 

WebAuthn leverages industry-standard cryptographic algorithms and protocols to ensure the highest level of security. It utilizes the [authenticators](https://auth0.com/blog/not-all-mfa-is-created-equal/#Factors--Authenticators--and-Assurance) to confirm the user's identity and create highly secure public-private key credentials. There are two types of authenticators: roaming authenticators, like hardware security keys, and platform authenticators, like your laptop or device, that support biometrics, such as fingerprint recognition, facial recognition, and voice recognition, depending on the capabilities of the user's device.

### Seamless user experience

With WebAuthn, users can authenticate with a single gesture or action, providing a convenient and frictionless login experience. While delivering a seamless and convenient authentication experience for users, it also enhances security.

## WebAuthn Roles

**Relying Party** - This is the website or online service the user wants to access. The relying party initiates the WebAuthn authentication process and verifies the user's identity.

**WebAuthn Client Device** -  The user's device (e.g., smartphone, computer) that supports WebAuthn and communicates with the relying party. It is capable of hosting the private keypair in secret storage that a user can access through biometrics or PIN.

**User** -  The individual attempting to access a relying party's website or services.

**Authenticator** - There are two types of authenticators, i.e., Platform Authenticators and Roaming Authenticators. 
  
Platform Authenticators refer to a specific type of authenticator built into the user's device or platform, such as a smartphone, laptop, or desktop computer. For example, a smartphone's fingerprint sensor or a laptop's built-in biometric recognition system can act as a platform authenticator. 
  
Roaming Authenticators are authenticators not tied to any particular platform but can be used to authenticate across multiple devices. They are also sometimes referred to as cross-platform or external authenticators. e.g., hardware security keys like the YubiKey.

<include src="WebAuthnMeCTA" group="A"/>

## How WebAuthn Works

WebAuthn's mode of authentication consists of a Registration Flow and an Authentication Flow. With WebAuthn, there are no longer shared credentials between the user and the relying party. A public-private key pair is generated with the help of the authenticators and is used instead of the password. Let us look into the user journey of the registration and authentication flows.

### Registration flow

#### A User visits a website

The process begins when a user visits a website or a web application that supports WebAuthn for authentication and requests the website to create a new account.

#### Initiating registration

The website, often called the relying party, begins the registration process. It generates a unique and cryptographically random challenge and communicates to the user's browser that it wants to register a new public-private key pair for the user.

#### The User chooses an authenticator to generate a public-private key pair

The user selects their preferred authenticator, a platform authenticator (built into their device, e.g., fingerprint sensor), or an external authenticator (e.g., a hardware security key). The chosen authenticator generates a new public-private key pair for the user and signs the challenge generated by the relying party with those keys. 

#### The Authenticator sends back the user credentials

The private key is securely stored within the authenticator, while the public key is sent back to the website along with the signed challenge and an optional private key ID.

#### The Website stores the user credential

The website stores the user's public key and the private key ID (if sent) and associates it with the user's account for future authentication; 

![WebAuthn Registration Flow](https://images.ctfassets.net/23aumh6u8s0i/6tOAUn8BVSqRrvnoe9fekn/d4614b12e493faeefc6d3cfaf36f3245/WebAuthn_Registration_Flow.png) 

The registration process is completed, and no more shared secrets are exchanged over the network between the user and the server, eventually reducing the risk of stolen credentials.

### Authentication flow

Once the user's registration is complete, the returning user can verify the credentials and log in to the application. Following are the steps that take place in the authentication flow for the user.

#### User returns to the website 
When users return to the website to access the protected resources, the web application prompts the user to authenticate. The user provides the username to the server.

#### Website generates an authentication challenge
The website generates a new challenge and sends it to the user's browser.

#### User requests authenticator to sign the challenge
The user selects the authenticator they used during registration, or the authenticator may be automatically detected and requested to sign the challenge. 

#### Authenticator signs the challenge
The authenticator signs the challenge using the private key stored during the registration flow. The authenticator sends the signed response and the public key back to the website.

#### User verification
The website receives the signed response and the user's public key. It verifies the response by checking the signature against the stored public key. If the verification is successful, the website grants the user access to the requested resources.

![Authentication Flow](https://images.ctfassets.net/23aumh6u8s0i/5gbfSpwf2b3EOAP4gP1elm/ae3db34de58eca086f963d06303c54cb/WebAuthn_Authentication_Flow.png)

The user is authenticated securely without a password and with less friction to the user.

## How to Implement the WebAuthn API

Two methods in the WebAuthn API mediate between the user and the server to create the public-private key pair.

1. `navigator.credentials.create`
2. `navigator.credentials.get`

### Using the "navigator.credentials.create" method

The `navigator.credentials.create` method is used to initiate registering a new credential for a user. This method allows users to create a new credential, such as a public-private key pair, which can be used for secure authentication in the future. Here's how you can use `navigator.credentials.create`.

#### Prepare credential creation options
You need to define the options for the credential creation request. These options specify various credential creation parameters, such as the relying party ID (your website's domain), user information, and allowed authenticator types (e.g., platform authenticator or external security key).

Here's an example of how to create credential creation options:

```
const publicKey = {
  challenge: new Uint8Array(/* Generate a random challenge */),
  rp: {
    name: 'Webauthn Me', // Relying party name
    id: 'webauthn.me',     // Relying on party ID
  },
  user: {
    id: new Uint8Array(/* Generate a unique user ID */),
    name: 'jane.doe@example.com',
    displayName: 'Jane Doe',
  },
  pubKeyCredParams: [
    { type: 'public-key', alg: -7 }, // ES256 algorithm
  ],
  timeout: 60000, // 1-minute timeout
  attestation: 'direct', // Attestation type
};

```

The following section describes each variable in detail.

- `challenge`: A challenge is a random value generated by the server and included in the registration request that helps to prevent replay attacks. The challenge serves as a nonce (number used once), ensuring that each registration request is fresh and not subject to replay. It prevents attackers from intercepting and reusing a valid registration message to gain unauthorized access. The server should validate the response promptly and reject it if the challenge has expired or does not match.
- `rp`: The relying party is the entity that relies on WebAuthn for authentication. For example, it is the domain of the website that implements WebAuthn to enable secure user authentication. Validating the relying party information helps prevent phishing attacks.
- `user`: Information about the user who wants to register.
- `pubKeyCredParams`: It is an array that specifies the acceptable public key algorithms and parameters for the generated credential. The array consists of two properties,
    1. `type`: A string indicating the cryptographic algorithm to be used. Common values include "public-key" for ECDSA (Elliptic Curve Digital Signature Algorithm) or "rsa" for RSA (Rivest–Shamir–Adleman)
    2. `alg`: An integer representing the specific algorithm within the given type. For example,`-7`representing ES256 for ECDSA with SHA-256.
- `timeout`: The time limit for the credential creation process.
- `attestation`: The attestation parameter specifies how the authenticator (e.g., security key, biometric device) should attest to the authenticity of the public key credential it generates during the registration process. The attestation parameter can take different values, each representing a different attestation type. Common values include:
    1. `none`: No attestation is requested. The authenticator generates a credential without any assertion of its authenticity. This is suitable for scenarios where the relying party already has a secure means of verifying the authenticator.
    2. `direct`: The authenticator provides an attestation statement, but the format and content depend on the authenticator type. This is also known as "self-attestation."
    3. `indirect`: The authenticator forwards an attestation statement obtained from a third-party service, typically the manufacturer or a trusted party.

#### Call "navigator.credentials.create"
Use the `navigator.credentials.create` method to initiate the credential creation process.

```
navigator.credentials.create({ publicKey })
  .then((credential) => {
    // Handle the successful credential creation
    // Send the credential information to your server for storage
  })
  .catch((error) => {
    // Handle any errors that occurred during credential creation
  });

```
`publicKey`:  It is the variable defined in the previous step. 

#### Handle the Credential Creation Response
If the user successfully creates a credential, the `navigator.credentials.create` promise will resolve with a credential object. You should send this credential object to your server for storage and associate it with the user's account.

```
// Handle the successful credential creation
// Send the credential information to your server for storage
navigator.credentials.create({ publicKey })
  .then((credential) => {
    // Response object has information about the authenticator data, 
    // public key, transport mechanisms, and more.
    const response = credential.response;

    // Access attestationObject ArrayBuffer
    const attestationObj = response.attestationObject;

    // Access client JSON
    const clientJSON = response.clientDataJSON;

    // Return authenticator data ArrayBuffer
    const authenticatorData = response.getAuthenticatorData();

    // Return public key ArrayBuffer
    const pk = response.getPublicKey();

    // Return public key algorithm identifier
    const pkAlgo = response.getPublicKeyAlgorithm();

    // Return permissible transports array
    const transports = response.getTransports();
    
    // Send the credential information to the server for storage
    return credential;
  })
  .catch((error) => {
    // Handle any errors that occurred during credential creation
    console.log('FAIL', error)
  });


```

If the credential creation fails or if there are errors, the promise will be rejected, and you can handle the errors accordingly.

Remember that the server-side storage and management of user credentials are essential for the WebAuthn authentication process. The server should securely store the user's public key and other relevant information to enable future authentication.

### Using the "navigator.credentials.get" method

The `navigator.credentials.get` method is part of the WebAuthn API and is used to initiate the process of authenticating a user based on the credentials they have previously registered. This method is typically used in conjunction with the `navigator.credentials.create` method for credential registration. Here's how you can use this method.

#### Prepare authentication options
You need to define the options for the authentication request. These options specify the criteria for the user's credentials for authentication. You can include the relying party ID (e.g., your website's domain) and specify the allowed authentication methods.

Here's an example of how to create authentication options:

```
const publicKey = {
  challenge: new Uint8Array(/* Generate a random challenge */),
  rpId: 'webauthn.me', // Relying party ID
  allowCredentials: [
    {
      type: 'public-key',
      id: /* The credential ID of the user's registered credential */,
    },
  ],
  userVerification: 'preferred', // or 'required'
};
```

The following section describes each variable in detail.

- `userVerification:` It specifies the preferred user verification method that the relying party wishes to be performed during the WebAuthn authentication process. The [userVerification parameter](https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/User_Presence_vs_User_Verification.html) can take different values, each representing a different user verification method. Common values include `required`, `preferred`, and `discouraged.`
- `allowCredentials:` It is an array that contains one or more "PublicKeyCredential" objects representing the credentials that the relying party is willing to accept during the authentication process. Each element in the allowCredentials array is an object with the following properties: 
  1. `type`: A string specifying the type of the credential. Commonly, this is set to "public-key".
  2. `id`: A byte array representing the credential ID. This corresponds to a credential that was previously created during the registration process.
- `challenge` and  `rpId` are the same parameters used for the `navigator.credentials.create` method.

#### Call "navigator.credentials.get"

Use the `navigator.credentials.get` method to initiate the authentication process:

```
navigator.credentials.get({ publicKey })
  .then((assertion) => {
    // Handle the successful authentication assertion
  })
  .catch((error) => {
    // Handle any errors that occurred during authentication
  });
```

`publicKey`:  It is the variable defined in the previous step.

#### Handle the authentication response
If the user successfully authenticates, the `navigator.credentials.get` promise will resolve with an authentication assertion containing information about the user's successful authentication. You can then send this assertion to your server for verification.

```
// Handle the successful authentication assertion
// Send the assertion to your server for verification
navigator.credentials.get({ publicKey })
  .then((assertion) => {
    // Handle the successful authentication assertion
    // The assertion response has information about the authenticator data, 
    // signature, and user handle
     const response = assertion.response;

    // Access authenticator data ArrayBuffer
    const authenticatorData = response.authenticatorData;

    // Access client JSON
    const clientJSON = response.clientDataJSON;

    // Access signature ArrayBuffer
    const signature = response.signature;

    // Access userHandle ArrayBuffer
    const userHandle = response.userHandle;

    return assertion;
  }).catch((error) => {
    // Handle any errors that occurred during authentication
    console.log('FAIL', error)
  });
```

If the authentication fails or if there are errors, the promise will be rejected, and you can handle the errors accordingly.

Remember that the server-side verification of the authentication assertion is an essential part of the process. The server should validate the assertion's signature and ensure that it matches a previously registered credential for the user.

These steps provide a high-level overview of how to use `navigator.credentials.create` and `navigator.credentials.get` in the WebAuthn API for user authentication. The actual implementation will vary based on your specific use case and server-side verification requirements.

## Conclusion

WebAuthn offers a passwordless and highly secure alternative to traditional authentication methods. Leveraging public key cryptography, user verification methods like biometrics, and a challenge-response model, WebAuthn effectively mitigates the risks associated with phishing attacks and enhances online security. It's important to note that while WebAuthn is phishing-resistant, it is not immune to all types of attacks. Therefore, proper implementation and security best practices on both the client and server sides are crucial to harness the security benefits of WebAuthn fully. [Auth0 supports WebAuthn](https://auth0.com/blog/mfa-with-webauthn-for-fido-device-biometrics-now-available/) and adheres to industry best practices and security standards, removing the heavy lifting of implementing on your own. It is a simple toggle switch in the configuration to show up in your login box, and all the background processing is taken care of by Auth0.

<include src="SignupCTA" text="Try out WebAuthn with Auth0?" linkText="Get started →" />

WebAuthn - A Short Introduction

kaycie-east

As PR Manager, Kaycie supports public relations and global communications efforts for Auth0 in the AMER region. When not promoting the Auth0 brand, Kaycie can be found hiking, traveling, or searching for the next best bite to eat.

PR Manager, AMER Region

Kaycie East

New feature removes the need for passwords and offers unique progressive enrollment features, paving the way for the ultimate user experience.


**BELLEVUE, Wash. – June 15, 2021 –** The [Auth0](https://auth0.com/) Identity Platform, a product unit within Okta, today announced the launch of [Auth0 WebAuthn Passwordless](https://auth0.com/passwordless), an authentication feature that enables end-users to seamlessly log in with a biometric identifier — such as facial recognition or a fingerprint — as a convenient and secure alternative to a traditional password. Removing the need for long, complex passwords, Auth0 WebAuthn Passwordless provides a frictionless experience for end-users while reducing the significant password management burden for companies. 

<include src="WebAuthnMeCTA" group="B"/>

Today’s abundance of applications and systems have never had more access points, leaving organizations and their end-users vulnerable to attacks. A reliance on passwords as a primary means of authentication, combined with users’ tendency to re-use passwords across applications, presents a number of security, user experience, and cost issues. According to a [2021 Data Breach Investigations Report by Verizon](https://www.verizon.com/business/resources/reports/dbir/), compromised passwords are responsible for 84% of breaches. Passwordless authentication mitigates these challenges and offers increased security and trust for applications, devices, and services providers; faster and smoother login experiences for their end-users; and cost savings by eliminating the need for password management support. 

“Despite ongoing guidance around proper password creation and repeated warnings against password reuse, consumers crave convenience and continue to use the easiest and most convenient path for application access,” said Shiv Ramji, Chief Product Officer at Auth0. “A passwordless future is largely being driven by two primary forces — security and convenience. Companies want to secure the vulnerabilities that come with passwords, and they also want to offer their users a better digital experience. Auth0 WebAuthn Passwordless is a modern option for organizations looking to attract and retain users.”

With Auth0 WebAuthn Passwordless, users can authenticate with Web Authentication-powered (WebAuthn) biometrics, the official web standard for passwordless authentication as published by [W3C and used by FIDO](https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/), for first-factor authentication. This form of authentication eliminates security weaknesses based on password reuse since passwords are not required. Additionally, Auth0 WebAuthn Passwordless is an ideal option for companies looking to build and provide an authentication experience supporting conversion and retention of users who want more choice and less friction in their login experience.

Auth0 WebAuthn Passwordless eliminates the need for users to enter username and password credentials and enables simpler login with a biometric identifier such as facial recognition like Apple Face ID or a fingerprint scan on a mobile device or laptop. The biometric data remains stored on the device, alleviating privacy and security concerns for end-users. The feature also allows end-users to progressively enroll devices one at a time, as they use them, without needing a centralized portal, giving them the flexibility of having multiple passwordless authentication options — an advanced, unique capability that maximizes end-user adoption and enables a faster transition from passwords to passwordless, benefiting both end-users and organizations.

More detailed information on Auth0 WebAuthn Passwordless can be found here: [7 Things You Need to Know About Passwordless Authentication](https://auth0.com/resources/whitepapers/passwordless-authentication) (whitepaper) and on [Auth0’s blog](https://auth0.com/blog/freedom-from-passwords-with-auth0-webauthn-passwordless). 

[Auth0, recently acquired by Okta](https://auth0.com/blog/okta-acquisition-announcement/), provides a modern identity platform that helps organizations meet the security, privacy, and convenience needs of their users. Please visit [The Auth0 Identity Platform](https://auth0.com/identity-os) to learn more.


<include src="asides/AboutAuth0" />
### Media Contacts
Global Communications<br />
Auth0 <br />
[press@auth0.com](mailto:press@auth0.com)<br />

Matter for Auth0<br />
[auth0@matternow.com](mailto:auth0@matternow.com)<br />

Auth0 WebAuthn Passwordless Offers New Levels of Ease and Security for Modern Authentication

andres

I’ve been at Auth0 since 2017. I’m currently working as a Product Manager for the Auth0 FGA and OpenFGA products. Previously, I worked in the teams that owned the Login and MFA flows. <br>
I spent my entire 20+ year career building tools for developers, wearing different hats. When I'm not doing that, I enjoy spending time with my family, singing in a choir, cooking, or trying new kinds of local cheese.

Product Manager

Andrés Aguiar

WebAuthn Authenticators offer a streamlined user experience and enhanced security

In the last few years, the [FIDO Alliance](https://fidoalliance.org/) has been working relentlessly towards the vision of helping users authenticate with maximum security and minimum friction. The resulting [WebAuthn standard](https://www.w3.org/TR/webauthn-1/) provides the foundation for that to happen. Now it is up to the industry to make that technology available to end users. 

WebAuthn is the only standard-based authentication method that makes phishing impossible, as it binds the public/private key to a specific web domain. You cannot mistakenly authenticate into a phishing website.

A few weeks ago, [we announced](https://auth0.com/blog/fido-security-key-support-comes-to-auth0/) the support for [FIDO Security Keys for MFA](https://auth0.com/docs/mfa/fido-authentication-with-webauthn) using WebAuthn. Security Keys are a great way to secure access to your account, but their adoption is mostly limited to tech-savvy users or corporate environments with relatively high-security requirements.

We are now announcing support for [**FIDO Device Biometrics for MFA using WebAuthn**](https://auth0.com/docs/mfa/fido-authentication-with-webauthn). This makes the security and convenience of WebAuthn-powered flows available to anybody who has a device and browser who can support the biometric challenge, not just those who have security keys. Now all users can reap the benefits of this technology, regardless of how tech-savvy they are. 

<include src="WebAuthnMeCTA" group="A"/>

Enabling users to authenticate using their device biometrics has two benefits: it **greatly reduces friction** during the authentication challenge, which impacts user **retention and revenue**, and **it increases security** since the flow is not phishable by bad actors. 

The data we collected during Beta testing shows biometrics performing much better than other MFA options:

![Internal Auth0 study, March 2021](https://images.ctfassets.net/23aumh6u8s0i/wD2JeWObWymymRv7Xs7gf/8d5c021776667b1e87d691cf7429e37a/graphics.jpg)
<p align="center"><i>Internal Auth0 study, March 2021</i></p>
<br>

The Y axis shows time to complete, and the X axis represents the % of users that can complete the MFA challenge. WebAuthn platform authenticators have the highest passing rate (94%) and the shortest time to complete (5 seconds).

## WebAuthn With Device Biometrics Availability

For users to take advantage of biometric authentication on the web, they need to have devices that support WebAuthn. It’s hard to know precisely how many devices are capable of WebAuthn Device Biometrics, as there is no specific information. We can only approximate with operating system and browser usage statistics, as in Android and Windows, it depends on the device in addition to the OS/Browsers.

<table border="1">
<tbody>
<tr>
<td><b>Operating System & Browsers with WebAuthn Device Biometrics Support</b></td>
<td><b>OS Adoption March 2021 Source: <i>StatCounter</i></b></td>
</tr>
<tr>
<td>Mac OS Catalina (Chrome, Edge, Brave)</td>
<td><a href="https://gs.statcounter.com/os-version-market-share/macos/desktop/worldwide#monthly-202103-202103-bar">67%</a></td>
</tr>
<tr>
<td>Mac OS Big Sur (Chrome, Edge, Safari, Brave)</td>
<td>Unknown</td>
</tr>
<tr>
<td>iOS 14+ (Safari)</td>
<td><a href="https://gs.statcounter.com/os-version-market-share/ios/mobile-tablet/worldwide#monthly-202103-202103-bar">76.24%</a></td>
</tr>
<tr>
<td>Windows 10 + (All modern browsers)</td>
<td><a href="https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide#monthly-202103-202103-bar">78.28%</a></td>
</tr>
<tr>
<td>Android 7+ (Chrome)</td>
<td><a href="https://gs.statcounter.com/android-version-market-share/mobile-tablet/worldwide/#monthly-202103-202103-bar">82.08%</a></td>
</tr>
</tbody>
</table>
<br>

You can get additional information about browser support on our [webauth.me](https://webauthn.me/browser-support) site.

## Enrolling With Device Biometrics

Authenticating using WebAuthn with Device Biometrics presents two unique challenges:

* Given the authentication method is bound to a specific device, it cannot be **the only** authentication method the user has, or they will be unable to log in from a different device. 
* Users would want to use biometrics to login from all of their devices, and applications should make it possible to enroll all of them.

Auth0’s solution addresses both problems. It will always ensure that users’ have another way to authenticate. When MFA is enabled, users can only enable biometric authentication if they also enable another option.

The enrollment flow would be as follows:

![The enrollment flow](https://images.ctfassets.net/23aumh6u8s0i/skfRYpG6f4PbJAfT5jcji/98afcec8e1653c389b6344099a2ff003/unnamed-2.png)

* The user authenticates with a username and password.
* Enrolls in any other MFA Factor (e.g., a security key, a TOTP application like Google Authenticator, Push, SMS)
* If the device is capable of using Webauthn Device Biometrics, users will get the option of enrolling with it.
* If they do, the next time they login from that device, they can use Device Biometrics as the second factor.

#### Progressive Enrollment

Auth0 employs progressive enrollment to aid users in authenticating from different, WebAuthn-capable devices. Whenever a user presents this type of device for authentication, they will first be prompted to enroll it. This is a progressive process that is only activated once new, WebAuthn-capable devices are used so that they will be able to authenticate with biometrics in all of their devices capable of this functionality. 

For example, when a user initially authenticates from a MacBook with a Touchbar, they authenticate with their username and password and enroll in another MFA factor. However, since the MacBook has biometric capabilities, they will be prompted to enroll if they like. Later, if they wish to use their iPhone with FaceID capabilities, they will be automatically asked to use Face ID before proceeding. This process guides users through a progressive enrollment flow that is easy, seamless, and friction-free.

Here’s a quick demo of WebAuthn with Auth0:
<include src="Vidyard" id="CPw4UfSZxmTPkFvJSEC1x2" />

## Enabling WebAuthn With Device Biometrics

If you are currently using MFA with Auth0, biometrics can be enabled from the Auth0 dashboard. 

![Auth0 dashboard](https://images.ctfassets.net/23aumh6u8s0i/4UC4NaiiciIpjLGBPwab9h/07ea4d71950ba229bd3be05d8fb48696/unnamed-3.png)

After you enable it, users will receive prompts from enrolling their devices when authenticating; no code change is necessary.

Please refer to our documentation to learn more about [Auth0’s WebAuthn implementation](https://auth0.com/docs/mfa/fido-authentication-with-webauthn) in general and [WebAuthn for Device Biometrics](https://auth0.com/docs/mfa/configure-webauthn-device-biometrics-for-mfa) specifically.

## What’s Next

WebAuthn with Device Biometrics combines two authentication factors in one: something you have (the device) and something you are (the biometrics). In case you can’t use biometrics in the device, e.g., if you are wearing a mask, you’ll use something you have plus something you know (the passcode). As it’s stronger than a password and simpler to use, the next step is bringing it to passwordless authentication. Auth0 will support this in the same way we are doing it for MFA by letting users progressively enroll all of their devices. Stay tuned!

MFA With WebAuthn for FIDO Device Biometrics Now Available

Login to web apps quickly and securely using a finger or face biometrics

The average person has to keep track of approximately [100 passwords](https://tech.co/news/average-person-100-passwords) and spends almost 13 minutes every week resetting those passwords. Due to this friction, password reuse is a major issue with over [two-thirds of end users](https://lp-cdn.lastpass.com/lporcamedia/document-library/lastpass/pdf/en/LastPass-B2C-Assets-Infographic-global.pdf) reusing passwords across sites, creating widespread security vulnerabilities. The [Verizon Data Breach Investigations Report (DBIR)](https://www.verizon.com/business/resources/reports/dbir/) found that credential vulnerabilities are involved in more than 80% of all data breaches. Since password reuse is so common, a single compromised password can endanger multiple accounts. 

Auth0 was the [first IAM system](https://auth0.com/blog/auth0-passwordless-email-authentication-and-sms-login-without-passwords/) to build support for passwordless authentication, and all of these reasons are as pertinent as ever:

* **Passwords are insecure:** users pick insecure passwords and reuse them across sites. Since [data breaches are common](https://www.securitymagazine.com/articles/94991-first-ever-identity-management-day-is-april-13-2021) and they frequently include password information, this creates a situation where more and more sites are vulnerable to hacking attempts.
* **Passwords are expensive to manage:** users forget them, and resetting passwords can be an [expensive and time-consuming process](https://quicklaunch.io/what-is-passwordless-authentication-and-how-it-works).
* **Passwords negatively impact customer retention:** remembering and typing a password, particularly on a phone keyboard, carries friction, and can cause returning customers to abandon the login flow, therefore impacting retention.

We believe that moving away from passwords as an authentication method is key to making the internet safer while reducing friction and positively impacting user acquisition and retention. 

Since our initial release, the authentication industry has been hard at work finding better ways to implement passwordless authentication. For example, the [FIDO Alliance](https://fidoalliance.org/) successfully led the specification and implementation of [WebAuthn](https://www.w3.org/TR/webauthn-1/). In the last few years, Webauthn has been implemented in all major OS/browsers, with iOS 14 and iPadOS 14 being the latest to join the party in September 2020.  

![WebAuthn](https://images.ctfassets.net/23aumh6u8s0i/3DuYOoznWG10geDOeYwBVm/02b5dbc23075eebf4d984f22dbaaec76/Passwordless-Authentication-sep2.jpg)

### WebAuthn as an Authentication Method

WebAuthn provides the combined benefit of minimum friction with maximum security. Webauthn not only has a better [completion rate (95%) than other authentication methods, but it also has a lower time to complete (5 seconds)](https://auth0.com/blog/mfa-with-webauthn-for-fido-device-biometrics-now-available/).

Together, these characteristics mean that when you use WebAuthn for passwordless sign-in, you can expect [higher end-user conversion and retention](https://www.cio.com/article/3193206/ditching-passwords-and-increasing-ecommerce-conversion-rates-by-54.html). 

When it comes to security, WebAuthn uses public-key cryptography instead of shared secrets, and it’s the only standard authentication method on the web today that is considered unphisable[^1]. When using platform authenticators, given its reliance on the device’s biometric sensors, it is easy to use and familiar for end users.

WebAuthn allows users to authenticate using one of two methods:

* **Roaming authenticators:** These are removable and cross-platform, such as a [Yubikey](https://www.yubico.com/products/) that can be used on multiple devices. To use a roaming authenticator, you simply connect it to the device (through USB, NFC, or Bluetooth), provide proof of presence (e.g., touching it), and optionally an additional factor like a PIN or fingerprint scan. 
* **Platform authenticators:** This includes the MacBook’s TouchBar, Windows Hello, iOS Touch/FaceId, and Android’s fingerprint/face recognition. Since they are integrated into the device being used, these only work on that device. 

Auth0 shipped support for [using both Platform and Roaming authenticators as a second factor](https://auth0.com/docs/mfa/fido-authentication-with-webauthn) earlier this year.

<include src="Vidyard" id="1CQ91oVKty61AJD5BnA1rS" />

### One authentication method, two authentication factors

When you combine WebAuthn with biometric authentication, you are performing multi-factor authentication with a single action. You are logging in with both:

* Something you have (the device where you are logging in, which has been registered as yours)
* Something you are (fingerprint or face recognition), or something you know in case you are wearing a mask and need to use the passcode. 

This means that in addition to removing the need to use a password, users can avoid being prompted for another authentication method when two authentication factors are needed. This is not only more secure but greatly enhances the user experience and removes a common friction point. If your application requires MFA, but you have been struggling with implementing it without impacting usability and conversion rates, WebAuthn is a great option.

![WebAuthn](https://images.ctfassets.net/23aumh6u8s0i/24uCeR7yhZbNmMpbFE7v3v/c2245aa707cc9d83b5242357ed06ac39/Passwordless-Authentication-sep1.jpg)

### Helping users adopt WebAuthn Biometrics

While the biometric systems market is experiencing significant growth - from [36.6 billion USD in 2020, expecting to reach 68.6 billion in 2025](https://www.marketsandmarkets.com/Market-Reports/next-generation-biometric-technologies-market-697.html), millions of users still log into websites using username and password credentials. Auth0 sees this as an opportunity to develop biometric authentication workflows that ease login for end users while also simplifying implementation for developers.

<include src="WebAuthnMeCTA" group="B"/>

If you’re already using Auth0, **implementing WebAuthn does not have to be difficult for your end users**. Auth0’s WebAuthn biometrics implementation enables **Progressive Enrollment**, which greatly simplifies enrollment for user devices by meeting them where they are. When a user authenticates with their username and password, Auth0 detects whether the device supports WebAuthn with Biometrics. If it does, it allows the user to decide whether they want to enable it. Once enabled, the next time they login with that device, it will use biometrics.

To enable this feature for your users, go to the Authentication Profile section in the Auth0 dashboard and configure the login flow to use “Identifier First + Biometrics”.

![WebAuthn Biometrics](https://images.ctfassets.net/23aumh6u8s0i/2kFxgRyXnnT2ZpWKAPh7sA/ee3e87868340dad1d999635f4cfb4ebc/WebAuthn_screen.png)

## Start your passwordless journey NOW!

Given the [wide availability of](https://webauthn.me/browser-support ) devices that support WebAuthn with Device Biometrics, and Auth0’s progressive enrollment implementation, you can start today to make your application more secure and your users happier, one user at a time.

[^1]: [https://www.w3.org/2018/Talks/06-WebAuthn.pdf](https://www.w3.org/2018/Talks/06-WebAuthn.pdf)

Auth0 WebAuthn Passwordless with Device Biometrics is Now Available

tyler-nix

Tyler’s professional experience spans engineering, architecture, sales, and product at companies ranging from a small Series B startup to a large Fortune 5 enterprise. He now uses his diverse experiences to build better products at Okta. When he is not scaling digital products, he is pursuing hobbies that inherently don’t scale (especially those outside). He loves hearing his kids laugh while riding bikes, spotting a new bird species, and watching his garden grow.

Tyler Nix

WebAuthn is an exciting technology, maximizing security without sacrificing user experience


Since ancient times, we have used passwords to grant access to privileged information. Guards allow access to buildings if correctly presented with a password. Soldiers exchange passwords and counter password to correctly identify each other. Even 8-year old secret societies allow entry to magical tree forts after declaring the super-duper secret passphrase. And when computers were first invented, how did we decide how to secure them? Passwords! Because, well, that’s all we had.

But if there is anything that we have learned since Robert Morris first started storing login passwords in a hashed form in the 1970s, it is that passwords are messy. They are [hard to remember](https://www.digitalinformationworld.com/2019/12/new-password-study-finds-78-of-people-had-to-reset-a-password-they-forgot-in-past-90-days.html), [easily guessed](https://nordpass.com/most-common-passwords-list/), and [annoying if leaked](https://www.pcmag.com/how-to/what-to-do-when-youve-been-hacked). 

## We Are Getting Better

However, in recent years, we have become more clever in securing digital accounts past just passwords. The two most significant things you can do to make yourself more secure online:

1. Use a [Password Manager](https://www.nytimes.com/wirecutter/blog/why-you-need-a-password-manager-yes-you/) to create and store unique passwords for each of your accounts.
2. Turn on [Multi-factor Authentication](https://auth0.com/blog/multifactor-authentication-mfa/) for all your highly sensitive accounts (like your bank and email).

But passwords, those things you and I have to remember if we ever want to use anything on the internet a second time, are still at the heart of the login process. Your password is the single key that proves you are, in fact, you. If a hacker manages to steal it, they can fully impersonate you unless you are one of the [28% of users using two-factor authentication.](https://duo.com/blog/state-of-the-auth-experiences-and-perceptions-of-multi-factor-authentication)

Passwords are messy.

## How Can Webauthn Help

As of January 2021, all major browsers like Chrome, Edge, Firefox, and Safari now support the [Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API) meaning we now have the ability to use Public Key Cryptography to register and authenticate users instead of passwords! You might be saying to yourself, “Public Key - what??” Don’t worry. You don’t need to understand the underlying technology to use WebAuthn. If that is you, you can skip to the next section. Otherwise, let’s dive into the details.

Public key cryptography is a relatively old concept but relatively new to user passwords. Ironically, it was invented in the 1970s, around the same time our friend Robert Morris was starting to store hashed login passwords. Public key cryptography uses the concept of a key pair; a private key that is stored securely with the user and a public key that can be shared with the server. These “keys” are long, random numbers that have a mathematical relationship with each other. This technique essentially became the cornerstone that [secures most of the modern internet](https://robertheaton.com/2014/03/27/how-does-https-actually-work/). However, its brilliance of shared secrets was never really applied to managing user passwords... until now!

The Web Authentication API (also known as WebAuthn) is a [specification written](https://www.w3.org/TR/webauthn/) by the World Wide Web Consortium (W3C) and The Fast IDentity Online Alliance, known as FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. WebAuthn allows users to authenticate with public-key cryptography using one of two options:

* Roaming authenticators &mdash; These are removable and cross-platform devices, like a [Yubikey](https://www.nytimes.com/wirecutter/reviews/best-security-keys/) that can be used on multiple devices. To authenticate with a roaming authenticator, you simply connect it to the device (through USB, NFC, or Bluetooth), provide proof of presence (e.g., touching it), and optionally an additional authentication factor like a PIN or fingerprint recognition.
* Platform authenticators &mdash; This option includes the MacBook’s TouchBar, Windows Hello, iOS Touch_FaceId, and Android’s fingerprint_face recognition. Integrated into the device being used, these only work on that device.

![Authentication Flow](https://images.ctfassets.net/23aumh6u8s0i/3b9M189ZcgQtfKSXZEahwv/c4dba7f38fa463f6ffcecb2119117c86/01_auth_flow.jpeg "Authentication Flow")

In the context of this article, we are focusing on Roaming Authenticators, but just know that WebAuthn enables both, opening up a lot of possibilities for secure user authentication in the future.

<include src="WebAuthnMeCTA" group="B"/>

## How to Set up and Use a Security Key

What you will need:

* A laptop or desktop
* A modern browser installed, either Chrome, Firefox, Edge, or Safari.
* A hardware security key, the two best options are [Yubikey](https://www.yubico.com/store/#yubikey-5-series) or [Google Titan](https://cloud.google.com/titan-security-key). Mine looks like this:

![Hardware Security Key](https://images.ctfassets.net/23aumh6u8s0i/7mBoXFhZzqf2vTX3wKothh/f45aa6be66b9b3ab3bc0e862b1d8c735/02_hardware_security_key.jpeg "Hardware Security Key")

**Note:** Before getting started, be aware of what you are about to do. You are about to register a hardware security key as a second form of authentication for your various accounts. **If you do not have this key physically present with you when logging in, you will not be allowed to continue**. It would be wise to enable Two Factor Authentication initially via a Temporary One Time Passcode mobile app like [Authy](https://authy.com/) or using text messages sent to your phone number. This ensures that if you ever lose your security key, you can still use a second form to sign in. If you have not done this yet, you should do this now.

And if you haven’t downloaded and saved your recovery codes in a secure location like a password manager, you should do that as well. Recovery codes can be used to access your account in the event you lose access to your device and cannot receive two-factor authentication codes.

### How to set up a security key with Google

1. Log in to your [Google](https://myaccount.google.com/) account from your browser.
2. Choose Security from the options on the left-hand side.
![Security key with Google](https://images.ctfassets.net/23aumh6u8s0i/jQzUlqMi2cDQgxvWLKzqU/8d68e6505fa8c675d9f538c08517f6a4/03_security_key_with_google_01.jpeg "Security key with Google")

3. Under Signing into Google, select 2-Step Verification.
![Security key with Google](https://images.ctfassets.net/23aumh6u8s0i/5u7erpiTmNNVa43HfUCfWa/568482c8665c6adf3f2460239b333876/04_security_key_with_google_02.jpeg "Security key with Google")

4. Under the Add more second steps to verify it’s you section, choose Add Security Key.
![Security key with Google](https://images.ctfassets.net/23aumh6u8s0i/3BF0d9LDRrQX72RRWn5rBq/bdb3d13d7ee0ce4a083efc453ca7d207/05_security_key_with_google_03.jpeg "Security key with Google")

5. Choose USB or Bluetooth option.
![Security key with Google](https://images.ctfassets.net/23aumh6u8s0i/SfHemm8cvxs61oxZjh8Je/7a5c9edc7a65c9113d06637177512c95/06_security_key_with_google_04.jpeg "Security key with Google")

6. Follow the instructions to register your security key.
![Security key with Google](https://images.ctfassets.net/23aumh6u8s0i/4qoZAYZax8XwiX2EpMT1yv/0d9ce7c036874c7efb90c1e3aeb162a8/07_security_key_with_google_05.jpeg "Security key with Google")

7. Once completed, you should see your named security key as the default option (since it is the most secure) to finish signing in after you enter your password.
![Security key with Google](https://images.ctfassets.net/23aumh6u8s0i/37DgmLP4YkwhLh1WlvKt2t/91e76e7b8a0d68a95c8d5f6534653e3a/07_security_key_with_google_06.jpeg "Security key with Google")

### How to set up a security key with Twitter

1. Log in to your [Twitter](https://twitter.com/) account from your browser.
2. Click on More and choose Settings and Privacy.
![Security key with Twitter](https://images.ctfassets.net/23aumh6u8s0i/1oHkhxSEmtT2wNKY49WpTa/73f77589542621d3bf8e9023f8940643/08_security_key_with_twitter_01.jpeg "Security key with Twitter")

3. Select Security and account access and then Manage your account’s security.
4. Select Two-factor authentication.
5. Click the Security key check box.
![Security key with Twitter](https://images.ctfassets.net/23aumh6u8s0i/5vWoUU7mIS6ouNjBnjMkRV/38f07de9bf5392ba3154ef87828f28f0/09_security_key_with_twitter_02.jpeg "Security key with Twitter")

6. Follow the instructions to register and verify your security key by touching it.
![Security key with Twitter](https://images.ctfassets.net/23aumh6u8s0i/2tMaL6UsrLIOAATKMoCYjx/ff49c458c66f57e8b8b965dba395ec10/10_security_key_with_twitter_03.jpeg "Security key with Twitter")

7. Your key should now be registered with Twitter.
![Security key with Twitter](https://images.ctfassets.net/23aumh6u8s0i/F5eEnT4BOGVILJ6jNtWZA/5262032803c0e0da5093969ffc38d69e/11_security_key_with_twitter_04.jpeg "Security key with Twitter")

### How to set up a security key with Github

1. Log in to your [GitHub](https://github.com/) account from your browser. 
2. Click on your profile image in the top right, and choose Settings.
![Security key with Github](https://images.ctfassets.net/23aumh6u8s0i/2O9KATj48kSAzV9CpXdSXn/896653ff07a309236ceabc091facc645/12_security_key_with_github_01.jpeg "Security key with Github")

3. Select Account Security, then Add.
![Security key with Github](https://images.ctfassets.net/23aumh6u8s0i/7FlPdqNW69mIJ38Dkig2BL/f6671aca1a71a7224fbca573b39bf280/13_security_key_with_github_02.jpeg "Security key with Github")

4. Under Security keys section, register your new security key.
![Security key with Github](https://images.ctfassets.net/23aumh6u8s0i/1Zl3MYe9UiWaA0Ih0hy8hw/f6dac28da88f9a446d4a067b93014aff/14_security_key_with_github_03.jpeg "Security key with Github")

5. Enter a name for this security key.
6. Follow your browser’s steps to register your security key.
7. Insert your security key into your computer and touch it. 
8. Your key should now be registered with GitHub!
![Security key with Github](https://images.ctfassets.net/23aumh6u8s0i/4kua0N7QM8zC3y2PHTypcD/406e672efcffca3df2403f9e629210ed/15_security_key_with_github_04.jpeg "Security key with Github")

It is that easy! You have now made a giant leap in securing your digital life all thanks to WebAuthn. 

On a day-to-day basis, you may not be required to use your hardware key all that often. Services often consider different risk factors to determine whether to require it. Some sites may ask you to enter it when you’re managing what kind of authentication you’re using, while others may ask you to use your key only when you’re logging in from a new computer.

## How to Set up Security Keys for Your Company

If you manage a company’s customer identity access management, then giving users more secure ways to protect their accounts can drastically reduce your risk. One of the easiest (and most secure) ways for you to implement WebAuthn with Security Keys for your website is allowing Auth0 to manage it for you. 

A Beta release of Auth0 with WebAuthn support for Security Keys is available starting today. You can enable the second factor in the WebAuthn with Security Keys MFA configuration section of the Auth0 admin dashboard:

![Security Keys for Your Company](https://images.ctfassets.net/23aumh6u8s0i/4u8PPLPBkktBasuyA5rfJW/baf9ac172457257001902a51a850dad4/16_security_keys_for_your_company_01.jpeg "Security Keys for Your Company")

After it is enabled, users will go through the enrollment flow below. At some point, their browser will show a native dialog to ask users to engage the security key. In the example below, we show the Android dialog:

![Security Keys for Your Company](https://images.ctfassets.net/23aumh6u8s0i/67mLa4gSwO48DW3SSepofu/00cf7adc623946693f92661cb95c3b97/17_security_keys_for_your_company_02.jpeg "Security Keys for Your Company")

The next time they login, the flow will look like this:

![Security Keys for Your Company](https://images.ctfassets.net/23aumh6u8s0i/6TWq0ebOknQ41urkuqrKQU/9cfaa0365656a2a5df489f86b64ba5fc/18_security_keys_for_your_company_03.jpeg "Security Keys for Your Company")

## Passwordless Future

Now let me give a fair warning, we are still on the cutting edge of this technology. Even though browsers now support it, most companies have been slow to adopt WebAuthn, and where there is support, it is only used as a second form of authentication. In other words, we are still a few years from seeing true passwordless user authentication, but it is a start - a very promising start.

What we need is more people insisting that companies start implementing WebAuthn as a primary form of authentication. And the best way to do that is by demonstrating there is public demand for such feature requests by utilizing what is currently offered today.

WebAuthn is an exciting technology, and Auth0 is committed to providing the best possible implementation, maximizing security without sacrificing user experience. Please [try our Beta](https://auth0.com/docs/mfa/configure-webauthn-with-security-keys-for-mfa) today and let us know what you think on our [Feedback page](https://auth0.com/feedback) or in the  [Auth0 Community](https://community.auth0.com/) .

<include src="asides/AboutAuth0" />


Using WebAuthn to Secure Your Digital Life

Announcing support for WebAuthn with FIDO Security Keys for Multi-Factor Authentication in Auth0



Companies of all sizes are under attack, targeted by numerous phishing attacks that are coming at an ever-increasing rate. Even if the tech industry continues to improve how organizations identify and defend against those attacks, the problem is bigger than ever. According to ProofPoint's [2020 State of The Phish Annual Report](https://www.proofpoint.com/sites/default/files/gtd-pfpt-uk-tr-state-of-the-phish-2020-a4_final.pdf), 88% of organizations faced a targeted phishing attack in 2019, and 65% of US organizations experienced a **successful** phishing attack.

There are options for decreasing the chances of successful phishing attacks targeting your company. Things like employee training and security policies, such as using password managers and enforcing multi-factor authentication (MFA), are all steps in the right direction. 

However, if you want to neutralize the threat completely, you need to enable authentication methods that cannot be phished. That's [what Google did](https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing) in 2017 to neutralize phishing of its employees. Google now requires all employees to use U2F Security Keys to authenticate to corporate websites. 

U2F evolved into the WebAuthn specification, which is now supported by the latest versions of browsers and operating systems. Auth0 is now supporting WebAuthn with FIDO security keys for multi-factor authentication. You can start protecting your users with Auth0 today, using the same technology as Google.

## About WebAuthn

The Web Authentication API (also known as WebAuthn) is a [specification](https://www.w3.org/TR/webauthn/) written by the World Wide Web Consortium (W3C) and The Fast IDentity Online Alliance, known as FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. The API allows servers to register and authenticate users with public-key cryptography instead of a password.

When it comes to security, many people think you have to sacrifice security in the name of user experience, and vice versa. However, the key to maximizing both variables is to reduce the number of times we prompt the user for authentication and to allow the user to authenticate with secure factors that provide low friction. WebAuthn promises to be the holy-grail of authentication factors, as it accomplishes exactly that by combining maximum security with a low-friction user experience.

WebAuthn allows users to authenticate using one of two options:

* **Roaming authenticators** — These are removable and cross-platform devices, like a [Yubikey](https://www.yubico.com/products/) that can be used on multiple devices. To authenticate with a roaming authenticator, you simply connect it to the device (through USB, NFC, or Bluetooth), provide proof of presence (e.g., touching it), and optionally an additional authentication factor like a PIN or fingerprint recognition.

* **Platform authenticators** — This option includes the MacBook's TouchBar, Windows Hello, iOS Touch/FaceId, and Android's fingerprint/face recognition. Integrated into the device being used, these only work on that device.

When doing multi-factor authentication, we want to challenge the user with something they know (like a password), something they have (like a security key), and something they are (e.g., their fingerprint).

Note that a Roaming Authenticator + PIN **combines two factors in one** (you have the key, and you know the pin), and a Platform Authenticator also does (you have the device, you are the person with that fingerprint/face, or you know the passcode).

In recent months the WebAuthn API has been implemented in major browsers and operating systems, enabling support for both options.

<include src="WebAuthnMeCTA" group="A"/>

## The Case for Security Keys

Using a Security Key allows you to authenticate users with the strongest possible authentication factor. This helps you to solve several problems at once by:

* Protecting sensitive data and employee accounts
* Providing secure access from outside the corporate network
* Allowing your employees to authenticate to shared computers
* Enabling MFA in scenarios where users cannot carry their mobile phone

It also offers several advantages when compared with using a smartphone only authenticator for MFA:

* Protects against phishing and man-in-the-middle attacks
* Strengthens user privacy as it doesn't require a personal device
* Provides one-touch login without having to take your mobile phone to complete an authentication challenge
* Has no battery or signal dependency
* Has no moving parts, so it's practically indestructible
* Allows users to register multiple keys, minimizing business disruption and the chances of account lockout

## WebAuthn With Security Keys for Multi-Factor Authentication

Auth0 with WebAuthn support for Security Keys is available starting today. You can enable the factor in the WebAuthn with Security Keys MFA configuration section of the admin dashboard:

![Multi-Factor Authentication 1](https://images.ctfassets.net/23aumh6u8s0i/5LAUWUPRO5gvYQ9t56rNPa/f9c2d823965b8070c22e6ab3151d2665/01-factors-updated)

After it is enabled, users will go through the enrollment flow below. At some point, their browser will show a native dialog to ask users to engage the security key. In the example below, we show the Android dialog:

![Multi-Factor Authentication 2](https://images.ctfassets.net/23aumh6u8s0i/4l0n2zVBk0Byf8P2MfWvaf/51a1b3ebb7248719a7cc17b32a4765a4/02-welcome)

The next time they login, the flow will look like this:

![Multi-Factor Authentication 3](https://images.ctfassets.net/23aumh6u8s0i/5f9tqz1pR3RgrkFZSOcp2F/41df6128ee37f040c0389dbd7db9dda8/03-waiting-for-your)

## Stay Tuned!

In addition to supporting WebAuthn with roaming authenticators, we are currently working on a unique approach that will greatly improve the usability and adoption of WebAuthn platform authenticators. Check out Vittorio Bertocci's session "[Democratizing WebAuthn for Developers and End Users](https://authenticatecon.com/session/democratizing-webauthn-for-developers-and-end-users/)" from FIDO's Authenticate conference for the scoop!

WebAuthn is an exciting technology, and Auth0 is committed to providing the best possible implementation, maximizing security without sacrificing user experience. Check out our new [WebAuthn](https://auth0.com/docs/mfa/configure-webauthn-security-keys-for-mfa) offering and let us know what you think on our [Feedback page](https://auth0.com/feedback) or in the [Auth0 Community](https://community.auth0.com).

<include src="asides/AboutAuth0" />


FIDO Security Key Support Comes To Auth0

Sam4-square

I'm an Identity nerd with many years of experience as a developer and advocate. I love explaining complex topics clearly and understandably. You can find me on stage at developer events worldwide or simply having great conversations in the hallway. Google has recognized me as a Google Developer Expert (GDE) in the domains of Web Technologies, Security, Privacy, Payments, and Identity.

Principal Developer Advocate

Sam Bellen

With resident credentials you can create a smoother, username-less login experience by saving some of the user data on the authenticator.


<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Want to learn more about WebAuthn? Then head over to <a href="https://webauthn.me/">webauthn.me</a> and don't forget to try the brand new debugger!</strong>
</div>

**TL;DR:** With the release of version 76, Google's Chrome browser [now supports WebAuthn resident keys](https://www.chromestatus.com/feature/4627499185078272). These allow for a smoother, username-less login experience by saving some of the user data on the authenticator. Let's have a look at how this works.

## WebAuthn Until Now

In a typical WebAuthn scenario, a credential ID is generated by the authenticator and saved on the server. This ID is used to identify the saved credential on the authenticator. We will save this credential ID linked to a username or other user identifiable property in our database.

When a user wants to authenticate using a previously created credential, they will enter their username in a login form. The server will look up the saved credential ID for this username and pass it along to the authenticator. The authenticator will then use this ID to select the correct credential to sign the authentication challenge.

This is a good solution, it eliminates the need for a password, and authenticates using the keys generated by the authenticator. The user still needs to enter a username every time they want to login. We can do better!

## Resident Credentials

When setting the `requireResidentKey` property to true, will force the browser to create a new client-side-resident public key credential source or resident credential for short, on the authenticator. With these resident credentials, the authenticator is able to select the appropriate credential private key based on the relying party ID.

For example, a user registers new credentials for the relying party with ID `auth0.com`. Any subsequent authentication request with that relying party will use the saved resident credential to find the corresponding credential private key unless an array of allowed credentials is configured in the `navigator.credentials.get()` options. 

To create a resident credential, you need an authenticator that is capable of creating one of these. Not all authenticators can do this. A Yubikey (4 or 5) and most other devices that support FIDO2 should be able to do this. There’s one caveat, your Yubikey should have a pin configured. If you don’t have an authenticator that supports resident credentials, it will throw an error.

## Step by Step

Let’s walk through this scenario step by step.

A user is new to your website and wants to configure a new credential using WebAuthn. You configured your relying party to set the `requiresResident` option to true, so the browser will try to create a resident credential.

Chrome will prompt the user which authenticator to use if it has found more than one.

![Choose an authenticator](https://images.ctfassets.net/23aumh6u8s0i/2xbPAhm7uuUnOoDctv9AZV/ddc965236705abf92d81d36cc602753f/choose-authenticator)

After selecting the authenticator of your choice, the browser will ask you to perform an action. In the case of my Yubikey 5C, it asks to touch the key. Note that it also mentions “A record of your visit to this site will be kept on your security key”. This “record” will be our resident key.

![Touch your security key](https://images.ctfassets.net/23aumh6u8s0i/2ntMji45OFRpMRd86vucC8/fde5589c360dd65b5fd6d152b30527ed/insert-authenticator)

If you don’t have a pin code configured on your authenticator, Chrome will ask you to do this at this point.

![Configure a pin code](https://images.ctfassets.net/23aumh6u8s0i/6EV7MFea4JlLilgVspP8ri/a3f5b33ac7ba4c8d65e30aada4cd9288/set-pin)

In case you already set up your authenticator with a pin code, you will have to enter the pin to continue.

![Enter your pin code](https://images.ctfassets.net/23aumh6u8s0i/38BniTjL2ASqlBEjwDDaSG/ff4258b36ae2300b830e62bce75c26c6/enter-pin)

To complete saving the resident credential, the browser will prompt a second time to confirm you want to create this credential.

![Confirm by touching your security key](https://images.ctfassets.net/23aumh6u8s0i/7BY9Q23ra2CXTEUmhqrKAW/888c98a897b180839b67ab4536a791bf/confirm-request)

We now have successfully registered a new client resident credential. When authenticating in the future, the browser will automatically use this credential, based on the relying party ID.

When there are more than one resident credentials saved on the authenticator, the browser will show a dialog where the user can select the credential they would like to use to authenticate.

![Choose which credential to use](https://images.ctfassets.net/23aumh6u8s0i/6IDvveTf1tv5n6TZjQL6o4/b02f58c082cb1d05a737cf3af3cb2099/choose-credential)

## Conclusion

After Microsoft's Edge browser already supported resident credentials, now also Chrome supports this feature. These kinds of credentials are saved on the authenticator, and allow the user to authenticate without even entering a username. The browser will recognize these credentials based on the relying party ID configured in the WebAuthn authentication request.

## Resources

[Introduction to Web Authentication](https://auth0.com/blog/introduction-to-web-authentication/)<br>
[webauthn.me](https://webauthn.me/)<br>
[WebAuthn Debugger](https://webauthn.me/debugger/)<br>




A Look at WebAuthn Resident Credentials

To help you understand the WebAuthn configuration objects we've added a debugger to the webauthn.me website.



## Introducing the WebAuthn Debugger

**TL;DR** We've written about one of the latest additions to the [W3C specs](https://www.w3.org/TR/webauthn/), the [web authentication API](https://auth0.com/blog/introduction-to-web-authentication/), before. The API requires many configuration objects that you may be seeing for the first time. To help you understand these configuration variables we've added a [debugger to the webauthn.me website](https://webauthn.me/debugger). It lets you play around with different configurations and test them on the fly.

The Web Authentication API has 2 methods. A `create()` method to register new credentials and a `get()` method to use previously created credentials.

## Creating Credentials

Let's start with looking at the configuration for the `create()` method. Below you'll find some example code on how to use the `navigator.credentials.create()` method with some configuration in place. Let's break it down.

```
navigator.credentials.create({
 publicKey: {
   challenge: Uint8Array([1, 2, ... 3, 4]),
   rp: {
     id: 'webauthn.me',
     name: 'WebAuthn debugger'
   },
   user: {
     id: Uint8Array([1, 2, ... 3, 4]),
     name: 'Sam Bellen',
     displayName: 'Sambego'
   },
   pubKeyCredParams: [
     {
       type: "public-key",
       alg: -7
     }
   ],
   timeout: 15000,
   excludeCredentials: [{
       type: 'public-key',
       id: Uint8Array([4, 3, ... 2, 1]),
       transports: ['USB', 'NFC', 'BLE', 'internal']
   }],
   authenticatorSelection: {
       authenticatorAttachment: 'platform',
       requireResidentKey: true,
       userVerification: 'preferred'
   },
   attestation: 'direct',
 },
})
.then(console.log)
.catch(console.error);
```

### Challenge

The challenge is a buffer of randomly generated bytes with a minimum of 16 bytes. This is generated on the server using a [cryptographically secure random number generator](https://nodejs.org/api/crypto.html#crypto_crypto_randombytes_size_callback). By generating the challenge on the server we can prevent "replay attacks". The authenticator will sign this along with other data.

### Relying Party

This is the entity which is responsible for handling all things authentication, usually your authorization server or identity provider (IdP). The id must be the current domain or a subset of it. The name is used to describe the relying party.

### User

The user object contains profile information about the user like its name and preferred display name. It also contains a user id which is again a buffer with byte values. To ensure secure operation, authentication and authorization decisions must be made based on this user id, not the name or display name. The user id can not contain information that can identify a user, like a username or an email.

### Public Key Credential Parameters

This is a collection of accepted public key types. The algorithm (alg) is a number that references a key type in[ this list of COSE algorithms.](https://www.iana.org/assignments/cose/cose.xhtml#algorithms)

### Timeout

Defines the maximum time in milliseconds the user has to complete the registration action. This can be touching their authenticator device, TouchID or any other method used to interact with an authenticator.

### Excluded Credentials

You can use this if you wish to limit the creation of multiple credentials for the same account on a single authenticator. Your browser will throw an error if you try to create a new credential while one of the public keys in this collection already exists on the authenticator.

### Authenticator Selection

You can limit the type of authenticator devices you allow to register new credentials with part of the configuration. 

#### Authenticator Attachment

Only allow platform authenticators like TouchID or Windows Hello. You can also do the opposite, and only allow cross-platform authenticators like a Yubikey or a Google Titan Security Key. 

#### Require Resident Key

When set to true, the private key is stored on the authenticator. This means that the user can login without entering a username. This can be done with the `user.id` property we’ve seen before. The relying party will create a user handle which is stored in the resident key on the authenticator when creating a new credential. When authenticating the authenticator will return the user handle, so the relying party can look up the user linked to this user handle.

#### User Verification

Use the user verification option to only allow or discourage authenticators that verify the user is performing the registration. By checking a fingerprint with TouchID or doing facial recognition with Windows Hello the authenticator can verify the user performing the registration.

### Attestation

An attestation object is returned when completing the registration. With this parameter, you can specify if you want the attestation data from the authenticator as is (direct), or you're fine with anonymized (indirect) data.

When you successfully register a new credential, the `create()` method will return a credential object. This contains the id of the newly created credential in base64 and binary (rawID). We'll use this ID when authenticating a registered user with the second method specified by WebAuthn, `navigator.credentials.get()`

## Authenticating a User with a Previously Registered Credential

So you've registered a new credential, and now you want to authenticate using that credential. Like the `create()` method, the `get()` method also accepts a configuration object. Let's have a look.

```
navigator.credentials.get({
 publicKey: {
   challenge: Uint8Array([1, 2, ... 3, 4]),
   timeout: 15000,
   rpId: 'webauthn.me',
   allowCredentials: [{
       type: 'public-key',
       id: Uint8Array([1, 2, ... 3, 4]),
       transports: ['USB', 'NFC', 'BLE']
   }],
   userVerification: 'preferred'
 }
})
.then(console.log)
.catch(console.error);
```

### Challenge

Just as when registering a new credential, this is a buffer with cryptographically random bytes with a minimum length of 16 bits. Make sure you generate this challenge in a trusted environment, like a server.

### Timeout

Again, the optional timeout sets the time the user has to complete the authentication action.

### Relying Party Id

Also optional, you can specify the relying party. By default, the browser will use the current domain.

### Allowed Credentials

This is a collection of credentials the server would like the user to use for authentication. The credentials are listed in descending order, meaning that the relying party prefers the first, then second, and so on. We will pass the id we got back when completing the registration here.

## Wrapping up

WebAuthn is a new approach for a key-based registration and authentication on the web. By going through the most commonly used parts of the config you should be able to set up your WebAuthn process just right.

If you're still not sure which setting is best for you, [visit the online interactive WebAuthn debugger,](https://webauthn.me/debugger) and see how changing some options can change the registration and authentication process and result. The debugger has an easy to use interface which let’s you change the configuration objects and test them. It’ll display the results after you’ve finished the WebAuthn request. 

Do you still have some WebAuthn questions after reading this blog post, leave a comment below!


Enhancing webauthn.me with the Online Debugger Tool

kapehe-jorgenson

Kapehe is an R&D Content Engineer for Auth0 with a passion for learning and teaching. With her primary focus on ReactJS and JavaScript, she is impressed with what code can create for the web. Technology and web development are constantly evolving and naturally bring that need for continual learning. She enjoys writing tutorials, hosting local meetups, and learning with others to expand coding knowledge.

R&D Content Engineer

Kapehe Jorgenson

Learn about WebAuthn with the interactive playground WebAuthn.me


<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
 Got a WebAuthn issue you can't wrap you head around? We have added a new online debugger tool that lets you play with different configurations and test them on the fly. <strong><a href="https://webauthn.me/debugger">Try it now</a></strong>
</div>

**TL;DR:** In this article, we will go over the WebAuthn specification and the newest resource, [WebAuthn.me, a fully interactive demo of the WebAuthn spec](https://webauthn.me/). We will go over how the identity scene is evolving and trending towards the mainstream adoption and enablement of strong authentication. Although the username and password combination will not be going anywhere for now, soon we may see more biometrics for authentication purposes.

## What is WebAuthn

[WebAuthn](https://www.w3.org/TR/webauthn/), otherwise known as Web Authentication, is an effort to strengthen the process that takes place on websites and applications when accepting user credentials. Extensive data breaches and user credential compromises keep the industry on its toes, always looking for stronger ways to authenticate.

We previously posted a great [introduction to web authentication, the new W3C spec](https://auth0.com/blog/introduction-to-web-authentication/). In summary, Web Authentication is a new W3C standard backed by major industry players like Google, Microsoft, and Mozilla. It aims at defining a web-browser API for the creation and use of strong authentication credentials based on public key cryptography. The core goal is to increase security for the authentication process by removing or complementing password-based authentication while remaining convenient for end-users.

<include src="TweetQuote" quoteText="WebAuthn is an effort to strengthen the process that takes place on websites and applications when accepting user credentials."/>

### How Does WebAuthn Work?

![Web Authentication (WebAuthn) Flow Example Diagram](https://images.ctfassets.net/23aumh6u8s0i/3Mrv3KSQL4dmgJmxzrwY9A/f3111e352a69f70fa914e614807acf59/flow.png)

[Source](https://webauthn.me/introduction)

The web browser is where most of the authentication process happens. It carries out two different actions:

1. Registration
2. Authentication 

### Registration

The registration process generates a new public key and then signs a challenge for the particular website you are trying to authenticate with. [The public part of these new credentials, along with the signed challenge, can be sent back to the relying party for storage.](https://webauthn.me/introduction)

> A [challenge](https://www.w3.org/TR/webauthn/#cryptographic-challenges), generally implemented with a very large random number, is used to avoid [replay attacks](https://en.wikipedia.org/wiki/Replay_attack).

![Web Authentication (WebAuthn) Registration Flow Example Diagram](https://images.ctfassets.net/23aumh6u8s0i/2rW0LG4aFyAtVOdpzcMWf2/31e57349a36a64f9fa2d60fb7690529c/updated-registration-flow.png)

[Source](https://webauthn.me/introduction)

### Authentication

The authentication process involves the user logging in to a website that they have already registered with. The challenge is sent to the “authenticator” to ensure that the connection between the user and the website is valid. Once authenticated, the sign-in process can continue and sign the user in fully.

![Web Authentication (WebAuthn) Authentication Flow Example Diagram](https://images.ctfassets.net/23aumh6u8s0i/50Bx4D6yPoeOH0W94mnhCn/87dc7bdd53eca6d5b4ca3bf9dbfbf239/updated-authentication-flow.png)

[Source](https://webauthn.me/introduction)

## [WebAuthn.me - Credential and Login Demo Site](https://webauthn.me/)

At Auth0, our mission is to make the internet safer. Identity and security are at our core. We have created an easy authentication process demonstration for users that shows how WebAuthn can ensure their security consistently.

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">At Auth0 we love creating tools that help developers 🎯. With <a href="https://t.co/WO25Momvyl">https://t.co/WO25Momvyl</a> you will learn everything you need to know about the <a href="https://twitter.com/hashtag/WebAuthn?src=hash&amp;ref_src=twsrc%5Etfw">#WebAuthn</a> protocol.<a href="https://twitter.com/hashtag/authentication?src=hash&amp;ref_src=twsrc%5Etfw">#authentication</a> <a href="https://twitter.com/hashtag/w3c?src=hash&amp;ref_src=twsrc%5Etfw">#w3c</a> <a href="https://twitter.com/hashtag/passwordless?src=hash&amp;ref_src=twsrc%5Etfw">#passwordless</a> 🔐</p>&mdash; Auth0 (@auth0) <a href="https://twitter.com/auth0/status/1084870715474612225?ref_src=twsrc%5Etfw">January 14, 2019</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

If we head over the [WebAuthn.me](https://webauthn.me/), we will see a six-step, interactive process that demonstrates how WebAuthn works. 

### Step 1: 

We will need to connect a USB authenticator or ensure that our device has a built-in one, like [Touch ID](https://support.apple.com/en-us/HT207054) for example. If we were on a mobile device, there is support for [NFC](https://www.gsmarena.com/glossary.php3?term=nfc) and [BLE](https://www.blemobileapps.com/ble-mobile/).

> When using the built-in authenticator device, like Touch ID on the Mac or fingerprint authentication on Android, these only work in Chrome at the moment.

Once we enter our username or email address and click the `Register` button, we are ready to continue on.

![WebAuthn Credentials and Login Demo - Step 1 - Register user on WebAuthn.me](https://images.ctfassets.net/23aumh6u8s0i/2n3WEZJkjWhzUgCLD93tPK/faacd2b9639fc4ccb4996ef85b02fa13/step-1)

While it is working, we will see an animation of a green dot being passed between the authenticator, the browser, and the relying party:

![WebAuthn Credentials and Login Demo - Step 1 Green dot animation moving](https://images.ctfassets.net/23aumh6u8s0i/6F7rFbwBYI8bPC20jqqxWk/14f094f53262a87dbf9f64814db7006d/step-1-process)

> In this particular step, it is the `challenge` that is being passed around.

### Step 2:

Once it continues on to step two, we will be prompted to choose which method we would like to use:

![WebAuthn Credentials and Login Demo - Step 2 Authentication method selection on WebAuthn.me](https://images.ctfassets.net/23aumh6u8s0i/6ORCofkcMxZjlgmIqNroYg/d0e9c53be49dc6d5020b9a90edb52b0e/options)

For this example, we are going to choose the "Built-in sensor" option.

> On my MacBook, I will be using my built-in Touch ID fingerprint sensor.

It will then prompt us to touch the `Authenticator` so it can read our fingerprint in order to continue on. Once we put our finger on the sensor, it will verify our fingerprint and move us on to step three of the process.

### Step 3: 

We now have our new credentials, our `rawId`, and our `public key`. These new credentials will be what is passed to the website that is needing to authentication. 

![WebAuthn Credentials and Login Demo - Step 3 rawId and public key created on WebAuthn.me](https://images.ctfassets.net/23aumh6u8s0i/6Y2XlxKk1Mz89apU7hqmVT/b5bdb6ec25c7e46f40f067b54b4ba249/step3)

Let's move on to step four of the process by clicking the `Next` button.

### Step 4: 

By using our new `rawId`, we can be authenticated as the authorized user! We will see our `rawId` was passed on to step four for us and by clicking `Login`, we can see the green dot get passed through the process again and then move us on to step five.

![WebAuthn Credentials and Login Demo - Step 4 rawId passed to Login on WebAuthn.me](https://images.ctfassets.net/23aumh6u8s0i/7wBlFVXXyx9J2xZnPa4sVz/fffc39da44fac332ee2b777aedb8d363/step4-login)

### Step 5:

In this step, we will be need to verify our fingerprint again so that we can complete the login process.

We will need to touch the `Authenticator` again. For us, that is verifying our fingerprint by using the built-in Touch ID: 

![WebAuthn Credentials and Login Demo - Step 5 Fingerprint verification with built-in Touch ID on WebAuthn.me](https://images.ctfassets.net/23aumh6u8s0i/1AujQZe2rKTvS4OjaanuU8/1a18383460e5ce8b2b07cb6ee41108f1/fingerprint-auth)

Once we do so, it will move us on to step six.

### Step 6:

The final step is seeing that our login process was successful!

![WebAuthn Credentials and Login Demo - Step 6 Authentication and Login successful on WebAuthn.me](https://images.ctfassets.net/23aumh6u8s0i/1pKD3sBF9uniyNKyRPPIQR/c88f078821dbf0a9d9c9871373d7434e/login-successful)

<include src="TweetQuote" quoteText="Head on over to webauthn.me to see a demonstration of the WebAuthn login and credential verification."/>

## Which Browsers Support WebAuthn?

Currently, only three main browsers support Web Authentication:

1. Chrome
2. Firefox
3. Edge

> To see a full list, [visit this website.](https://caniuse.com/#feat=webauthn)

And even with those, it is only partially implemented. This new way of authentication is still a work-in-progress.

WebAuthn is also available on [Safari Technology Preview](https://webkit.org/blog/6017/introducing-safari-technology-preview/), a version of Safari for OS X. The web authentication feature is behind a flag in a special version of Safari Tech Preview that needs to be enabled by the user. To learn more about it, visit the [Release Notes for the Safari Technology Preview 71](https://webkit.org/blog/8517/release-notes-for-safari-technology-preview-71/).

## Will This Get Rid of Passwords?

The username and password combination is not going anywhere, but we need to do more to mitigate phishing attempts. WebAuthn could fully replace the need for the username/password method, but for now, usernames and passwords will be sticking around. 

When using WebAuthn, the user's credentials that were stored cannot be used to impersonate the user even if they are stolen because they are encrypted with the authenticator's internal private key. That allows for databases to store user credentials in an encrypted form.

<include src="asides/AboutAuth0" />

## Conclusion

WebAuthn is another way to authenticate that could allow for less attacks on user's information. For now, the username and password combo is still alive and well, but WebAuthn could be what we see being implemented to authenticate users in the future. 

Auth0 provides the interactive playground [WebAuthn.me](https://webauthn.me/) to give a better understanding of this concept of authentication.


Launching WebAuthn.me - Overview & Login Demo

auziros:jeana-tahnk

Jeana has been in the tech industry for 15+ years, both as a communications professional and writer. As Director of Global Communications at Auth0, she works with her internal team and external agencies to amplify the company's visibility worldwide and establish its leadership in the identity industry. When she is not working, she can most likely be found on a field watching one of her three kids playing sports, or cleaning up after her one-year-old retriever who chews everything.

Senior Director, Global Communications

Jeana Tahnk

Passwordless and Multifactor Authentication motivate companies to shift their approach to customer logins.



**BELLEVUE, Wash. -- July 9, 2018 --** [Auth0](https://auth0.com), a global leader in Identity-as-a-Service (IDaaS), today announced key findings on how companies are approaching the Customer Login Experience as new technologies like Passwordless, Multifactor Authentication, and social login options become more prevalent. According to anonymized data collected in May from a large sampling of Auth0 customers across all verticals, including financial services, media, retail, transportation, SaaS, and more, Auth0 found that companies are eager to embrace and adopt methods for streamlining the login process, suggesting that we should see an increase in passwordless usage in the near future. 

The emergence of [FIDO 2.0](https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-overview-v2.0-rd-20170927.html) and [WebAuthn](https://auth0.com/blog/introduction-to-web-authentication) have encouraged more companies to take the leap into a passwordless future. Auth0’s customers are leading the charge, with 19.4 percent already using its [Passwordless](https://auth0.com/passwordless) feature, allowing developers to easily enable sign-in to apps without the need for passwords – a feature that Auth0 has offered since 2015. 

> Learn more and [try a WebAuthn demo crafted by Auth0, here](https://webauthn.me/).

The shift toward passwordless is a strategic one, considering that password changes are quite common for Auth0’s customers that use traditional username/password as a login method. Customers in the staffing & recruiting industry see 48.2 percent of their customers requesting a password change, followed by transportation (39.8 percent), federal (23.0 percent), and financial services (18.6 percent), the most common reason being forgotten passwords. “Gartner predicts that, through the end of 2020, enterprises that invest in new authentication methods and compensating controls will experience 50 percent fewer identity-related security breaches than peers that do not (Gartner).”<sup>[1](#myfootnote1)</sup>

As the industry evolves to a possibly passwordless future, the current state of the industry still finds a predominant use of passwords as the primary means of logging in. Before making the leap into passwordless, many companies have implemented [social login](https://auth0.com/learn/social-login) as an easier way to consolidate secure logins. 
 
Auth0 provides support for 30+ social providers, which 72 percent of its customers take advantage of, easing the login process for their users. The top five most widely used social login sites for Auth0 customers are: Google (60.3 percent), Facebook (24.1 percent), LinkedIn (8.8 percent), GitHub (7.1 percent), and Windows Live (6.8 percent). These percentages may shift in coming months based on recent news about how Cambridge Analytica handled Facebook data, which is a [cautionary tale](https://auth0.com/blog/cambridge-analytica-and-facebook/) for organizations about the implications of data breaches. 

With the prevalence of passwords still being used, the best way to protect identity credentials is to employ a feature like [Multifactor Authentication](https://auth0.com/multifactor-authentication) (MFA), which only 11.4 percent of Auth0 customers currently provide to their users. Of these customers, the top three industries consist of healthcare, manufacturing, followed by government. Adoption rates of MFA are on the low end due to the perception of added friction it supposedly creates for users, but it’s a critical feature for stopping phishing attacks, as well as decreasing the probability of getting hacked. In addition to this essential security layer, customers are relying on additional risk-based MFA that accommodates factors such as geographic location, IP filtering, type of device, which is a huge benefit with today’s global workforce. 

“The login experience is continually changing based on user demand and the need to protect against today’s sophisticated cybercriminal landscape. Passwordless is a signal of the kind of industry change we are all heading toward,” said Martin Gontovnikas, VP of Marketing and Growth at Auth0. “The insights we continually gather from our fantastic in-house data team fuel the continued innovation of our platform so customers stay several steps ahead in this constantly changing industry.” 

<a name="myfootnote1">1</a>: [Gartner Smarter with Gartner, Aim for a Workable Password Policy, Not a Perfect One October 9, 2017](https://www.gartner.com/smarterwithgartner/aim-for-a-workable-password-policy-not-a-perfect-one/)

<include src="asides/AboutAuth0" />

### **Media Contact:**

Jeana Tahnk<br>
Corporate Communications<br>
Auth0<br>
[jeana.tahnk@auth0.com](mailto:jeana.tahnk@auth0.com)

Kasia Hall<br>
Matter for Auth0<br>
[khall@matternow.com](mailto:khall@matternow.com)<br>
971-246-7898


Momentum Building for a More Streamlined Customer Login Experience, According to Auth0

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

Learn about WebAuthn, a new standard for secure authentication on the web.


[News](https://www.engadget.com/2018/05/09/mozilla-firefox-passwords-web-authentication-support/) about [Web Authentication](https://webauthn.me/introduction), or WebAuthn for short, reaching maturity and being enabled by default in web browsers hit the headlines recently. Web Authentication is a fairly recent W3C standard backed by major players like Google, Paypal, Mozilla, Microsoft, and Qualcomm. It aims at defining a web-browser API for the creation and use of strong authentication credentials based on public key cryptography. The driving force behind the proposal is to increase security for the authentication process by removing or complementing password-based authentication while remaining convenient for end-users. Although implementations are still in their early days, and the standard has not been finalized, the strong push from major players, and the fact that both Firefox and Chrome are enabling their implementations by default, are strong indicators that this may cause a significant impact in the authentication space. Let's check it out!

<include src="WebAuthnMeCTA" group="A"/>

---

## Introduction
The traditional username/password scheme for user authentication has been in use for decades. Even in the face of modern approaches like social logins and [Face ID](https://en.wikipedia.org/wiki/Face_ID), username and passwords remain the most popular and widely used mechanism for authentication. Stronger authentication mechanisms such as certificates and hardware tokens have been supported for a long time for specific applications and use cases, but they remain unusual for end users.

Most of the authentication flows performed by end users are done through web browsers. In a sense, web browsers have become the nexus between credentials and applications on the two major platforms: desktop and mobile. It is natural, then, that changes to authentication flows require support from browsers. The web, however, is built on consensus. This means that changes to the platform need to be implemented by several players. For this reason, the W3C WebAuthn Working Group was formed: to produce a new specification that can be implemented by all parties and that remains interoperable.

The draft specification says:

> This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users.

<include src="TweetQuote" quoteText="Web Authentication defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users."/>

To better understand Web Authentication, let's go through a quick overview.

## Web Authentication In a Nutshell
Let's take a look at the entities involved in WebAuthn:

![Web Authentication (WebAuthn) Entities](https://images.ctfassets.net/23aumh6u8s0i/5c7KKyElhmYWEPB4R8TQje/d46dec602523f6af3cb4d68b03e15232/1-Web-Authentication-Entities.png)

These entities work together in two separate use cases: **registration** and **authentication**. All communications between the different entities in the diagram are handled by the user agent (usually a web browser).

Registration makes the authenticator create a new set of public-key credentials that can be used to sign a challenge generated by the relying party. The public part of these new credentials, along with the signed challenge, can be sent back to the relying party for storage. The relying party can later use these credentials to verify the identity of a user whenever required.

![Web Authentication (WebAuthn) Registration](https://images.ctfassets.net/23aumh6u8s0i/2xxX1F2zya0XdsiCRz5dXk/3c3350168175e59b2e41be8afda3e9fd/2-Registration.png)

Authentication, in contrast, allows the relying party to send a challenge to the authenticator. This challenge can then be signed with the previously generated public-key credentials and sent back to the relying party. This way, the relying party can verify that a user is in possession of the required credentials, proving their identity.

![Web Authentication (WebAuthn) Authentication](https://images.ctfassets.net/23aumh6u8s0i/6iz4I2CXCV5CW7qNaSknTK/88fe1dd04f4bdde733d11f1fd947cfe4/3-Login.png)

Both processes work with the help of public-key cryptography and digital signatures. If you are not familiar with how public-key cryptography or digital signatures work, the important thing you must know is that there is a public key and a private key. The private key is secret, and only the user (or the authenticator) must know it. The public key, in contrast, is public and can be seen or stored by anyone. The public key can be used to verify signatures generated by the private key. No other key, other than the private key, can generate a signature that the public key can verify as valid. This way, the relying party can store a public key and use it to verify signatures performed by the user holding the private key.

Let's take a quick look at the actual API.

### API
The Web Authentication API has two main calls: [`navigator.credentials.create`](https://www.w3.org/TR/webauthn/#createCredential), and [`navigator.credentials.get`](https://www.w3.org/TR/webauthn/#getAssertion). There is also an [accessory API to list authenticators](https://www.w3.org/TR/webauthn/#isUserVerifyingPlatformAuthenticatorAvailable).

`create` can be used to perform the registration step. `get` can be used to perform the authentication step.

Here is a sample call of the `create` function inside an [EJS](http://ejs.co/) template:

```javascript
navigator.credentials.create({
  publicKey: {
    // random, cryptographically secure, at least 16 bytes
    challenge: base64url.decode('<%= challenge %>'),
    // relying party
    rp: {
      name: 'Awesome Corp' // sample relying party
    },
    user: {
      id: base64url.decode('<%= id %>'),
      name: '<%= name %>',
      displayName: '<%= displayName %>'
    },
    authenticatorSelection: { userVerification: "preferred" },
    attestation: 'direct',
    pubKeyCredParams: [
      {
        type: "public-key", alg: -7 // "ES256" IANA COSE Algorithms registry
      }
    ]
  }
}).then((res) => {
  var json = publicKeyCredentialToJSON(res);
  // Send data to relying party's servers
  post('/webauthn/register', {
    state: '<%= state %>',
    provider: '<%= provider %>',
    res: JSON.stringify(json)
  });
}).catch(console.error);
```

Here is a sample call of the `get` function in an EJS template:

```javascript
navigator.credentials.get({
  publicKey: {
    // random, cryptographically secure, at least 16 bytes
    challenge: base64url.decode('<%= challenge %>'),
    allowCredentials: [ {
      id: base64url.decode('<%= id %>'),
      type: 'public-key'
    }],
    timeout: 15000,
    authenticatorSelection: { userVerification: "preferred" },
  }
}).then((res) => {
  var json = publicKeyCredentialToJSON(res);
  // Send data to relying party's servers
  post('/webauthn/authenticate', {
    state: '<%= state %>',
    provider: '<%= provider %>',
    res: JSON.stringify(json)
  });
}).catch(err => {
  alert('Invalid FIDO device');
});
```

But the cool thing about all of this is that you don't need to care about any of it! If you use Auth0, you don't need to understand the gritty details of Web Authentication to use it.

<include src="TweetQuote" quoteText="Web Authentication at Auth0 will work with the flip of a switch!"/>

## A Working Web Authentication Implementation at Auth0
One of the cool things about our architecture is that changes in the login system can be integrated with little or no changes to client code. In other words, once our implementation of Web Authentication is released, enabling it for your apps will be a matter of making a few clicks in the [Auth0 Dashboard](https://manage.auth0.com/).

This is a proof-of-concept of how WebAuthn as a second factor will work in Auth0:

<video src="https://cdn.auth0.com/blog/webauthn/Auth0-Web-Authentication-2-small.mp4" title="Web Authentication proof-of-concept video - WebAuthn as a second factor with Auth0" controls autoplay loop></video>

What you see in this video is already working internally. We are eager to finish the implementation so you can start enabling Web Authentication in your apps.

Of course, there is more to Web Authentication than just using it as a second factor. We are also planning to enable Web Authentication as a **primary login solution**, that is, as a **passwordless login** mechanism. If you are not familiar with passwordless login and how it works, [take a look at our introduction](https://auth0.com/passwordless). Can you imagine logging in to your bank with just a push of your USB authenticator's button? <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up for an Auth0 account</a> and start improving your logins today. When WebAuthn integration is ready, enabling it for your apps will be a breeze.

<include src="TweetQuote" quoteText="Web Authentication (a.k.a. WebAuthn) is backed by major players in the industry, let's find out what it's all about!"/>

## Conclusion
Web Authentication brings a stronger authentication mechanism to the masses by defining an API that both authenticators and web browsers can implement. With the release of [Firefox 60](https://www.mozilla.org/en-US/firefox/60.0/releasenotes/) and [Chrome 67](https://www.chromium.org/developers/calendar), Web Authentication has become available to a big number of users. Authenticators, such as [Yubikeys](https://www.yubico.com/), already support the necessary protocols and work with current implementations. At Auth0 we care about providing the necessary building blocks for your identity infrastructure, and Web Authentication could eventually become a major improvement in security and user experience. If you would like to use Web Authentication with Auth0 for your product, let us know in the comments, or [contact us through our "Talk to Sales" contact form](https://auth0.com/).


"webauthn"