<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">

What is WebAuthn? Web Authentication Explained

In this article, we will take a deep dive into WebAuthn and some of its associated authentication concepts. We’ll go over the history of WebAuthn and help you better understand the benefits and challenges of using this standard of secure authentication. By the end of this WebAuthn guide, you’ll be able to fully define the concept and grasp how to incorporate it into your organization's security program and web applications. 

What is WebAuthn? 

WebAuthn is the API standard that allows servers, applications, websites, and other systems to manage and verify registered users with passwordless authentication such as a biometric or possession-based device authenticator. 

Developed by the World Wide Web Consortium (W3C), this specification supports popular web browsers including Chrome, Microsoft Edge, Firefox, Safari, and their mobile equivalents. WebAuthn uses public-key cryptography to securely register, manage, and authenticate devices and accounts with the appropriate servers.     

WebAuthn: Terms to Know

Grasping the full concept of WebAuthn requires you to understand numerous terms and acronyms often associated with WebAuthn. Some of these terms include: 

  • FIDO: Short for “fast identity online,” it's the set of specifications and framework set by the FIDO Alliance for standardizing high-security, passwordless authentication methods  
  • FIDO2: The framework for which WebAuthn operates, it’s an extension of FIDO for specifications that expand into allowing users to authenticate using common mobile and desktop devices    
  • CTAP: Short for Client-to-Authenticator Protocol, it's a component of FIDO2 that provides devices the interface for external authenticators using USB, Near Field Communication (NFC), or Bluetooth  
  • CTAP1: Protocol that defines the interaction between browsers, operating systems, and devices to enable two-factor authentication
  • CTAP2: Allows for passwordless and multi-factor authentication by defining the protocol that sets up communication between browsers, operating systems, and external authenticators such as FIDO security keys or mobile devices 
  • U2F: Stands for Universal 2nd Factor and sometimes known as FIDO U2F, it acts as the standard protocol for authentication, which allows users to access online accounts using a second factor, a physical authentication device such as a USB, NFC, or Bluetooth   
  • MFA: Short for Multi-Factor Authentication, it’s a system of user verification into an online service, application, or user account that requires a combination of two or more different factors, including something you know (password), something you have (token), or something you are (biometric) 
  • 2FA: Short for Two-Factor Authentication, it’s a type of multi-factor authentication that requires exactly two methods to verify a user’s identity  
  • UAF: Otherwise known as FIDO UAF and stands for Universal Authentication Framework, it provides the specifications and interface which support passwordless authentication options such as a USB, NFC, or Bluetooth

History of WebAuthn

The history of WebAuthn and its development starts with the inception of the FIDO Alliance — founded by the companies PayPal, Lenovo, Nok Nok Labs, Validity Sensors, Infineon, and Agnitio in 2012 with the purpose of exploring passwordless authentication solutions. They started with deploying FIDO, the first framework of passwordless authentication, in February 2014.

By December 2014, FIDO UAF and FIDO U2F were published and many companies, including Microsoft and Samsung, slowly started supporting it in their operating systems. Fast forward to 2016, the World Wide Web Consortium (W3C) launched new standards in web authentication as a result of the FIDO 2 APIs that were submitted by the Alliance. The whole idea was to create a new standard for strong, secure authentication across all web browsers and platforms.

All of this is what led to the official launch of WebAuthn in 2018 by the W3C. By March of 2019, WebAuthn became the official web standard for password-free logins and was fully supported by Chrome, Firefox, Microsoft Edge, and Safari. One of the most recent developments was in June of 2020 with the announcement that Apple would allow Face ID and Touch ID to be used as a WebAuthn authenticator.  

Limitations of Current Authentication Methods

Password-based authentication still remains the most common user-verification method for online web services despite recent innovations with the WebAuthn FIDO 2 framework. The issue, of course, is the vulnerability to cyber attacks that target passwords such as credential-harvesting phishing scams, brute force algorithms, or keystroke logging. Password management becomes a burden and users end up taking the more convenient route by constructing small and simple passwords.

There’s also the issue of limited security awareness by employees and other users who struggle to see when an email or website is a scam that wants them to submit their credentials. Worsening the issue, users have to create and monitor a high number of password-based accounts.

Other authentication methods also see their fair share of limitations. For instance, if an application was using certificate-based authentication, it comes with complicated infrastructure maintenance that is often worse than password-based authentication while at the same time, anyone can have access to a server as long as they have the certificate’s private key. 

WebAuthn Limitation of Methods 

Even some of the authentication methods supported by WebAuthn find their own issues. Because it focuses on going passwordless, you have to look at the drawbacks of biometric and device-based verification. Biometrics, for example, require one's personal data such as fingerprint, voice, or eye scan, and if stolen, present an invasion of privacy, giving a criminal access and the ability to commit far worse fraudulent crimes. 

The obvious limitation of using some kind of external device (or roaming authenticator) is that if the user were to lose the removable key, they wouldn’t be able to gain access to the system without reconfiguration. Additionally, if that device were to end up in the wrong hands, it could cause unauthorized access to a web application, network, or other server.    

Benefits of WebAuthn

The first huge advantage of WebAuthn stems from its purpose for being created — enhanced security. Going passwordless helps both organizations and individual customers avoid becoming targets of password-based attacks. WebAuthn is also accepted by tons of popular browsers, operating systems, and devices, so you aren’t restricted to using any specific or small set of systems. 

This solution also provides users a better overall user experience that offers convenience (they can log in faster without a password) and choice (they can authenticate using different methods, devices, and operating systems). WebAuthn is also flexible in its ability to offer users and businesses options for strong single-factor logins or multi-factor authentications that can be custom-designed, depending on the system being accessed.     

Last and certainly not least is the cost-benefit of WebAuthn — specifically for a business. Going passwordless lowers the operational expenses that come with a help desk and support for when users and customers need to reset their passwords. Avoiding passwords also frees up your IT resources to handle other projects as time doesn't need to be spent constantly managing user credentials.       

Challenges of WebAuthn

Enabling strong authentication with WebAuthn does have some drawbacks that need to be addressed in the future. Adoption, for instance, is an issue because even though nearly all types of browsers, operating systems, and devices support WebAuthn, most major web applications do not. Furthermore, for the ones that do support it, it's only for an additional factor of authentication and not the primary one — so you’re still using a password in most cases.   

A lot of this could be traced to the education required of a regular user when implementing WebAuthn. We’ve been so ingrained to use passwords for years that full adoption of WebAuthn to a business’ online accounts could cause confusion.

While user experience is enhanced because of the convenience and choice of WebAuthn, there is one aspect of it that may not be so appealing to everyone — consistency. Because of all the authentication options, every web application, operating system, and browser will use an entirely different verification process and unique journey for the user. This is something users would have to get used to because, in the past, all accounts consistently required just a traditional username and password.    

How Does WebAuthn Work

The WebAuthn API uses public-key cryptography, a process in which, upon registering a device to a new application or system, what’s known as the WebAuthn “relying party” will prompt the browser to generate a credential. The system then indicates the desired authentication method (either a biometric or possession) based on the registered device’s capabilities and approval from the user. 

Upon approval, a private-public key pairing is generated where the private key is assigned to the user and the public key is forwarded to the web application’s server for storage.  The public key is uniquely paired to the user’s identity based on all of the information created during the credential-generation process. 

Authenticating the User 

When a user is looking to obtain access to their web application account, the server will prompt the relying party to start a login “challenge” — giving the browser your credential information, including the authentication method. The user then needs to complete the challenge by fulfilling the authentication method (inserting the device, placing a thumbprint, speaking for voice recognition, etc.). If the credential (private key) matches the information in the server (public key), the user is given permission to access the system. 

Example of WebAuthn

WebAuthn can be better illustrated using a real-world example. Let's say a user wanted to create an account with a WebAuthn-supported application such as Gmail. For additional security after creating an account, they wanted to require a second factor of authentication using a YubiKey during login on their iPhone. 

Since iPhones, iOS, YubiKey, and Gmail (U2F only) are supported by WebAuthn, they can undergo the registration process, approve the authentication method, and create a credential for the second factor of verification. The server recognizes the YubiKey device in the respective iPhone (private key) as an identifier for the user in relation to the Gmail account (public key).  

With the registration complete, each time they re-logged into their Gmail, they would put their username and password and then be prompted to insert the YubiKey in the headphone slot of the iPhone — completing the second factor and passwordless login.  

Three Major Properties of WebAuthn

The WebAuthn standard is built on three major properties of secure authentication: strong, scoped, and attested. The first “strong” property refers to the fact that it can securely store the private keys necessary for the advanced cryptography process. This is because of the use of a hardware security module that effectively manages the encryption functions. 

Next is the “scoped” property, which directly addresses the threat of phishing. Key pairs must be originated from a true origin and not one that can be altered. Lastly is “attested” in which servers can verify the source of a public key because the authenticator is able to provide a digital certificate. This lets the server know that the public key came from a trusted source as opposed to a fraudulent one. 

Best Practices for Implementing WebAuthn

If you plan on undergoing WebAuthn implementation projects for your web applications, you and the development team will want to follow some guidelines to obtain optimal usability and security outcomes. To start, with so much control over the authentication process, be sure to prioritize user experience and offer multiple verification methods that won’t be burdensome to the user. 

Next, while the flexibility of WebAuthn is high, it's best to directly refer to the API specifications laid out by their engineers and developers for the best security results. Because of the strong, scoped, and attested security properties of WebAuthn, you’ll also want to budget time and resources dedicated to the complexities of changing over to this system as well as the difficulties users will have in recovering authentication tokens and keys.  

Everything here should be supplemented with adequate resources for employees, contractors, or customers that will be using this relatively modern authentication solution. Provide user training, plenty of how-to guides, a WebAuthn demo, and a solid help desk team to better socialize the new verification requirements. 

WebAuthn: Wave of the Future 

Passwordless appears to be the future of secure authentication, and WebAuthn certainly provides the framework to move in that direction. As more and more systems adopt this standard, you can expect a new journey each time you log into your favorite web applications full of biometric and possession-based verifications. 

Want to learn more? Book a free demo today to see how an all-in-one infrastructure management platform like StrongDM can help you manage authentication requirements.


About the Author

, Director, Global Customer Engineering, has worked in the information security industry for 20 years on tasks ranging from firewall administration to network security monitoring. His obsession with getting people access to answers led him to publish Practical Vulnerability Management with No Starch Press in 2020. He holds a B.A. in Philosophy from Clark University, an M.A. in Philosophy from the University of Connecticut, and an M.S. in Information Management from the University of Washington. To contact Andy, visit him on LinkedIn.

logo
💙 this post?
Then get all that strongDM goodness, right in your inbox.

You May Also Like

SAML vs. OAuth
SAML vs. OAuth: Everything You Need to Know
In this article, we will provide a high-level overview of the Security Assertion Markup Language (SAML) and Open Authorization (OAuth) information access frameworks. You’ll learn about the key similarities and differences between SAML and OAuth, the unique benefits of each framework, and specific use cases for each. By the end of this article, you’ll have a clear understanding of SAML and OAuth to help you determine which is right for your organization.
What Is Credential Stuffing? Definition, Prevention & More
What Is Credential Stuffing? Definition, Prevention & More
In this article, we’ll define credential stuffing and explain the risks that credential stuffing attacks pose to organizations and customers. We’ll cover recent examples of credential stuffing attacks and discuss how to detect and prevent them. By the end of the article, you should understand the full scope of credential stuffing, including how to protect your customers’ and employees’ account credentials with the right tools. 
Brute Force Attack: Types, Examples & Prevention
What is a Brute Force Attack? Types, Examples & Prevention
In this article, we’ll take a comprehensive look at brute force attacks: what they are, how they work, and the different shapes they can take. You'll learn about popular tools utilized by hackers and examples of brute force attacks in action. By the end of this article, you'll be able to understand critical prevention measures for brute force attacks.
The difference between SAML vs OIDC
The Difference Between SAML vs. OIDC
The main difference between SAML and OIDC is that SAML builds the trust relationship between the service provider (SP) and the IdP, whereas OIDC trusts the channel (HTTPS) that is used to obtain the security token.
The Differences Between SAML vs LDAP
SAML vs. LDAP: Everything You Need to Know
The difference between SAML and LDAP is that SAML is designed for cloud-based connections using only an IdP and SP to communicate user data. LDAP, however, is typically used for accessing on-premises resources by installing a client on the user's device to connect with a directory service.