What is WebAuthn? How to Authenticate Users Without a Password

Passwords are the default method for authentication on the web, but they are plagued with security problems. The 2021 Verizon Data Breach Investigations Report found that 61% of breaches involved credentials, and 81% of hacking-related breaches leveraged either stolen and/or weak passwords. A Google/Harris Poll study revealed that 65% of people reuse passwords across multiple or all accounts.

Clearly, relying on passwords alone for authentication is risky. But what are the alternatives? Enter WebAuthn – a new web standard for passwordless and multi-factor authentication. Developed by the W3C and FIDO Alliance, WebAuthn allows users to log in using biometrics, security keys, or their devices‘ secure authentication mechanisms. No more remembering countless passwords!

How WebAuthn Works: Public Key Cryptography 101

WebAuthn is built on public key cryptography. In this system, a pair of keys – one public and one private – are used for authentication. The public key is not sensitive and can be freely shared, while the private key is kept secure and never leaves the user‘s device.

Here‘s a simplified analogy:

Imagine you have a special lock box with two keys. One key can only lock the box (the public key), and the other key is the only one that can open the locked box (the private key). You can give copies of the "lock-only" public key to anyone. They can put messages in the box and lock it. But once locked, only you with your private "open" key can retrieve the contents.

In WebAuthn, the browser plays the role of the box. A website sends a unique "challenge" (like a random number) to the browser to lock in the box. The user‘s private key then signs this challenge and sends it back to the website. The website uses the public key to verify the signed challenge, proving the user‘s identity.

The WebAuthn API Flow

The WebAuthn API has two main methods: navigator.credentials.create() for registering a new login credential, and navigator.credentials.get() for authenticating with a previously registered credential.

Registration Example

// Example WebAuthn registration 
const createCredentialOptions = {
  publicKey: {
    rp: { name: "Acme Corporation" },
    user: {
      id: Uint8Array.from("some_user_id", c => c.charCodeAt(0)),
      name: "[email protected]",
      displayName: "John Doe"
    },
    challenge: Uint8Array.from("random_challenge_from_server", c => c.charCodeAt(0)),
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],
    authenticatorSelection: { authenticatorAttachment: "cross-platform" },
    timeout: 60000,
    attestation: "direct"
  }
};

// Create new credential
const credential = await navigator.credentials.create(createCredentialOptions);

In this example:

1. The web server sends a challenge and other information (Relying Party details, user info, acceptable credential types and parameters) to the browser.
2. The browser prompts the user to choose an authenticator (if there are multiple) and authorize the creation of a new credential.
3. The authenticator generates a new key pair and attestation. The private key is stored securely on the device. The public key and attestation are returned to the browser.
4. The browser sends the public key and attestation back to the server for validation and storage.

Authentication Example

// Example WebAuthn authentication
const getCredentialOptions = {
  publicKey: {
    challenge: Uint8Array.from("random_challenge_from_server", c => c.charCodeAt(0)),
    allowCredentials: [{
      type: "public-key",
      id: Uint8Array.from("previously_stored_credential_id", c => c.charCodeAt(0))
    }],
    timeout: 60000
  }
};

// Get credential
const credential = await navigator.credentials.get(getCredentialOptions);

The authentication flow is similar:

1. The server sends a challenge and allowed credential IDs to the browser.
2. The browser asks the authenticator to sign the challenge with the private key of one of the allowed credentials.
3. The authenticator prompts the user to authorize the signing (e.g., by touching a security key or using a biometric sensor).
4. The authenticator signs the challenge and returns the signature to the browser.
5. The browser sends the signature back to the server for verification against the stored public key.

WebAuthn vs. Other Authentication Methods

WebAuthn is often discussed in relation to other authentication protocols like OAuth 2.0 and OpenID Connect (OIDC). While they all deal with identity and access management, they serve different purposes.

• OAuth 2.0 is a framework for delegated authorization. It allows a user to grant a third-party application limited access to their data on another service, without sharing their login credentials. For example, "Sign in with Google" buttons on various websites use OAuth to access your Google profile info without you giving them your Google password.

• OpenID Connect builds an identity and authentication layer on top of OAuth 2.0. It allows the third-party application to verify the user‘s identity and obtain basic profile information.

• WebAuthn, in contrast, is solely focused on authentication – verifying that users are who they claim to be. It does not deal with authorization or user profile data.

However, these technologies can work together. For example, a website could use WebAuthn for secure passwordless login, and then use OAuth 2.0 and OIDC to allow the user to connect and authorize access to their social media profiles.

The State of WebAuthn Adoption

Support for WebAuthn is growing rapidly across web browsers and online services. As of 2022:

• All major browsers (Chrome, Firefox, Safari, Edge) support WebAuthn on desktop and Android platforms. Safari support on iOS is in development.
• Many prominent websites and applications have implemented WebAuthn logins, including Google, Microsoft, Apple, Twitter, GitHub, Dropbox, Salesforce, eBay, and more.
• A FIDO Alliance survey found that 39% of businesses are planning to roll out WebAuthn support within the next 12 months.

While WebAuthn adoption is not yet universal, its trajectory is promising. The standard‘s security benefits and ease-of-use for end users are compelling. For services already supporting security keys as a second factor via the older FIDO U2F standard, the upgrade path to WebAuthn passwordless authentication is relatively straightforward.

The Future is Passwordless

Passwords have been the default authentication method on the web for decades, but their weaknesses are becoming increasingly apparent. Data breach after data breach has shown the risks of relying on shared secrets that can be easily guessed, reused, and stolen.

WebAuthn offers a path forward, harnessing public-key cryptography to provide more secure and user-friendly authentication. By moving cryptographic operations to dedicated authenticator devices (whether external security keys or built into laptops and phones), WebAuthn reduces the attack surface and makes scalable credential theft much harder.

Of course, WebAuthn is not a silver bullet. Challenges remain around account recovery, device roaming, and user education. Compatibility with existing password-based flows and legacy systems must also be considered. Nonetheless, the broad support for WebAuthn from browser vendors, service providers, and security experts indicates its potential to transform authentication on the web.

As a web developer, it‘s worth exploring how WebAuthn can enhance your application‘s security and user experience. Libraries like webauthn-simple and webauthn.io can help accelerate implementation. Diving into the WebAuthn Level 2 specification and FIDO2 developer docs is also recommended to fully understand the protocol and its best practices.

In conclusion, while passwords won‘t disappear overnight, their long-term outlook is bleak. With a powerful, standardized alternative in WebAuthn, the web is poised for a passwordless future. By adopting WebAuthn, developers can help lead the way to a more secure and user-friendly authentication landscape. The benefits – for both users and service providers – are too significant to ignore. Farewell, "123456". You won‘t be missed.