WebAuthn, Passwordless and FIDO2 Explained: Fundamental Components of a Passwordless Architecture
When someone is told that passwords are going away in favor of a new, “password-less” authentication method, a healthy dose of skepticism is not unwarranted. After all, years of memorizing increasingly complex combinations of lower- and upper-case letters, numbers, and special characters have conditioned users to believe the fancier their password, the less likely they are to get breached.
While this isn’t entirely wrong, passwords are difficult to remember and rarely secure. Experts in the fields of data protection and information security now look towards new technologies to make system access much more secure.
Passwordless authentication refers to a system that does not require the use of passwords at all. A current IT security trend, the password is replaced by much more secure factors in passwordless authentication, allowing for smoother usability without compromising on the additional benefits of having multiple factors.
In this article, we will go in-depth on the basic building blocks of passwordless technology: WebAuthn, FIDO, CTAP, FIDO2, and how it all comes together for the user.
What is WebAuthn?
The Web Authentication API (WebAuthn) is a specification developed by the World Wide Web Consortium (W3C) and the FIDO Alliance, with participation from an international array of major technology companies – including Cisco Security through Duo Security – actively contributing to WebAuthn development.
The WebAuthn API allows servers to register and authenticate users using public key cryptography instead of a password. When built into browsers and platforms, it creates a private-public keypair (known as a credential), enabling passwordless authentication by connecting applications with strong biometric authenticators like Windows Hello or Apple’s Touch ID.
In summary, WebAuthn is a:
Browser API for Passwordless Authentication
Strong Authentication using Public Key Cryptography (which makes a credential)
A specification developed by W3C and FIDO Alliance
What is the FIDO Alliance?
The FIDO Alliance, an open industry association consisting of members from across the global tech world, works to develop technical specifications for non-password-based authentication. Their findings are based on public key cryptography, aligned with the technology used in WebAuthn. The Alliance additionally certifies that solution providers are interoperable and meet the specifications established—denoted as FIDO® Certified.
In the case of passwordless, we focus on CTAP1 and CTAP2 specifications.
What is the difference between CTAP1 and CTAP2?
Established by the FIDO Alliance, Client to Authenticator Protocol (CTAP) is a specification that describes how an application (such as a browser) and operating system communicate with a compliant authentication device via USB, NFC, or Bluetooth Low Energy (BLE).
CTAP1 focuses on a universal second-factor enablement
CTAP2 focuses on communication between applications (browsers, operating systems, etc.) and external authenticators. It is a key standard for FIDO2-certified passwordless authentication.
CTAP1 and CTAP2 are fairly interoperable, with most WebAuthn authenticators able to support both.
What is FIDO2?
FIDO2 is a standard that uses modern authentication technology to enable strong passwordless authentication. A joint project of the FIDO Alliance and the W3C, FIDO2 combines the Client to Authenticator Protocol (CTAP) with the Web Authentication API (WebAuthn).
What are some examples of FIDO2 authentication methods?
Biometric-capable devices and platform authenticators: These are built-in authenticators that require a biometric, PIN, or passcode. Examples include Apple’s Touch ID and Face ID, Windows Hello, or Android fingerprint and face recognition.
Roaming authenticators or security keys: FIDO2-capable hardware tokens use USB, NFC, or BLE to communicate user verification via biometric or PIN.
In short: FIDO2 Framework = WebAuthn + CTAP2, and there are a few options for FIDO2-specific authentication methods. Passwordless authenticators can also come in the form of mobile applications, like Duo Mobile.
So how do all the pieces — hardware and software — come together to make passwordless secure?
How does passwordless authentication work?
The most significant difference between password-based authentication and key-based passwordless authentication is that no shared secrets are used to gain access to systems to verify the user’s identity. Multiple factors are still at play without having users remember a complex string of characters, namely the inherence factor (something you are - biometrics) and the possession factor (something you have - a registered device). Stronger factors significantly improve the user experience and mitigate the risk of phishing, stolen credentials, and man-in-the-middle (MiTM) attacks.
A keypair (the aforementioned “credential”) is generated during passwordless authentication. This keypair is always made up of a private and public key. In essence, the public key serves as a (public) lock that can only be opened with the private key. The combination of key and lock is unique per application, which greatly increases data security. A generated credential only works for the application or website it was created for, decreasing risk of being phished through fraudulent sites.
To generate the key pair of private key and public lock, users must use either a “external authenticator” (e.g., a security key) or a “internal authenticator” (e.g., a fingerprint reader). When a user logs into a system, the private key is kept by the user, while the public key (or public lock) is sent to the system. The public key is used to decrypt the private key by the system to which the user wishes to log in.
If the encryption and decryption sequence is successful – when the private key fits into the public lock – the user is also the owner of the private key.
Registering a Security Key or Biometric
For users to use security keys or biometrics, they would first have to register their devices to the Duo Cloud Service or another remote server. A challenge is returned with the relaying party ID, and in the third step, the system will check the TLS and generate the public and private key pair. Once the credential is created, this signed challenge with the credential ID generated by the key/biometrics system is sent back to Duo or the remote server service along with the public key. Finally, in the fifth step, the information is verified and saved along with the public key.
Authentication Flow
The authentication flow when user's login to a web application is simple and what makes passwordless a worthwhile investment. Using a web browser, the user would access the application server. The server would send a request to the user’s device, and in step 3 we see that a signed challenge using the private key is sent over to the server. This is verified with the public key stored on the remote server/Duo. Access is either denied or granted based on the successful cryptographic exchange.
Start your passwordless journey today
While there are several ways to start your journey to a passwordless future, I hope that this article has helped to understand the fundamental building blocks for a passwordless architecture.
For more technical explainers, read our Administrator's Guide to Passwordless series or learn more about Duo's passwordless solution today.