WebAuthn Introduction

Life Before WebAuthn

Passwords were supposed to secure our bank accounts, social media accounts, and hosts of other sensitive data - in short, we rely on passwords to secure our online existence.

And yet passwords are susceptible to phishing and released to the public when websites are compromised or hacked. Over 80% of all hacking-related breaches are caused by stolen or weak passwords.

For developers, the complexity of passing those passwords securely through systems and storing them securely in hacker-proofed databases is a burdensome overhead.

Replacing the Password

The fact that a password is a shared secret makes it vulnerable. Public-key authentication doesn’t have that weakness, and the WebAuthn API enables servers to register and authenticate users using public key cryptography instead of a password. The WebAuthn standard is a universally accepted W3C specification developed in concert by Yubico, Google, Mozilla, Microsoft, and others. Web Authentication works in tandem with other industry standards such as Credential Management and FIDO 2.0 Client to Authenticator Protocol 2 (CTAP). CTAP is an application layer protocol used for communication between a client (browser) or a platform (operating system) and an external authenticator (YubiKey 5).

Databases are no longer targets because public keys are useless without the corresponding private keys. FIDO2 standards enable passwordless authentication between servers, authenticators and browsers.

How It Works

With WebAuthn, servers can integrate with authenticators such as the YubiKey, a USB token, a smart phone, Apple’s Touch ID, and Windows Hello. The private key is securely stored on the device, while the server stores the public key and randomly generates challenges for the authenticator to sign. The signature proves possession of the private key, and the random challenge prevents replay attacks.

fido2_building_blocks.png

A server provides the data that binds a user to a private-public keypair (credential). The data includes identifiers for user and service or organization (the relying party, or RP). The RP can be Amazon, Facebook, Google, or any other service that has adopted WebAuthn. When the user begins the registration process, the RP sends out a challenge. The user agent - typically a browser - responds by using the WebAuthn API to prompt the user’s authenticator to create a new keypair. The private key is used to sign the challenge generated by the RP. The user agent sends the public key, an identifier for the public key (credential ID), and the signed challenge back to the RP for storage. When at a later time the user wants to authenticate, the RP sends out the credential ID and a new challenge. The authenticator signs the challenge with the private key identified by the credential ID, and the user agent sends the signature back to the RP which verifies it, proving that the user is in possession of the previously registered private key.

On the Front End

To experience registration and authentication from the end user’s perspective, check out this demo.

On the Back End

fido2_app_architecture.png

In general, a FIDO2/WebAuthn authentication architecture involves a conversation between a computing environment controlled by a Relying Party and one controlled by the user to be authenticated.

The following sections in this guide describe the basic FIDO2/WebAuthn user flows:

  • Registration Sequence

  • Authentication Sequence

Building a WebAuthn Experience

The Yubico Developer Program provides workshops, documentation, implementation guides, APIs, and SDKs. To get started,

  1. Sign up to the Yubico Developer Program to access the resources for implementing the FIDO2 and Web Authentication specifications.

  2. Watch FIDO2 / Web Authentication webinars to learn more about the core concepts and how to integrate WebAuthn RP operations into an authentication server.

  3. Read the developer guide for an introduction to WebAuthn/FIDO2 using Yubico’s Java WebAuthn Server.