WebAuthn: Growth and challenges

In this article, we will cover some of the characteristics of FIDO2 WebAuthn, which give it an edge over other authenticators (factors). We will also dive into the usage and growth of WebAuthn from Okta’s perspective, along with some of the challenges we are trying to solve for customers here at Okta.

WebAuthn (Web Authentication) is one of the core components of FIDO2 specification, which, along with Client to Authenticator Protocol (CTAP), provides means for phishing-resistant authentication using public key cryptography. Almost all the major browsers and platforms support WebAuthn. 

Lately, we have seen how most of the conventional factors for multi-factor authentication (MFA) like SMS, push, and passwords have been targeted for phishing attacks and have resulted in account takeovers, monetary losses, and damage to the organization's credibility. FIDO2 WebAuthn stands out among the group of authenticators for being one of the phishing-resistant authenticators. It also provides ease of use compared to authentications like OTP and passwords, where the user must manually key in the information.

For starters, we can easily compare WebAuthn with a widely used factor, SMS. Traditionally most organizations use SMS for the MFA; not only is latency involved, but there is also a probability of not receiving the SMS combined with the possibility of entering the wrong code. WebAuthn would solve all these shortcomings and provide cost savings (SMS costs recurring money).

However, like everything else in the world, there is always a trade-off involved. WebAuthn (when device bound) has its shortcomings as well. The biggest one is the fact that it's not possible to recover the credentials if a user happens to lose them somehow. One can argue that it's by design from a security perspective. A close second would be the variances in the WebAuthn authenticators where something like security keys could be used across the machines; however, platform-based would be locked to the platform only (and in some cases to browsers). 

The characteristics categorized as shortcomings could be seen as temporal and possibly historical from a platform-based authenticator's perspective since the FIDO alliance is working toward addressing them along with significant platform vendors. We will be covering that in the second article in this series.

Growth of WebAuthn

As one of the leading players in the Identity space, we have some visibility into the distribution of WebAuthn authenticators and their growth over the period. It took a while for WebAuthn to become mainstream, even though the specifications were first published in 2016. As of writing this article, we had close to 3 million WebAuthn enrollments. The graph below shows how the authenticator support was implemented in 2020, and in just over three years, it's one of the fastest-growing authenticators, with over 600% growth year over year. Alongside the growth of all authenticators, we have also captured the growth of the security key usage, which is a subset of all WebAuthn authenticators.

ctjqQgYdsqdGOcf5G2AysZvh 35nIEKRqcSUshfBxYESFumjitczfyWSSj6W1WcctNobhGC24GJo6mJikZ63HOb6iP7D4HkAXB3jUQQcV MjLnIdbn2FPE1QseD mIDBnPPL7ngffz8Mpj04MBYk7XE

Another exciting piece of data is the distribution of the different types of WebAuthn authenticators. The pie chart below shows a high-level distribution of all the authenticators. The tail end of the variety is quite large, and for the purposes of this chart, we only captured the foremost authenticators. One remarkable fact is that Apple has a majority share of WebAuthn enrollments.


k6CgWR8FHltQeu0zhP4qH9V7hzZfHUnpzqiEVqgdOZGibN5GFaitGOaXmT Mc552VO3rcFvIWt W0XSiJWZ2uLuLRZfMQm1W7OhX0mZGbKBbxWIazGDK5aHMdlrkw8k5Uhdlq8gIoaKz3PtSGSNOwZI

Intricacies of WebAuthn

The WebAuthn flow has three core components:

  • Authenticator: This can be a hardware- or software-based piece that generates and stores the private key for each credential. The authenticator communicates with the Relying Party (server) via the client and uses a version of the CTAP protocol with the client. 
  • Client: This is the core component that mediates the registration and authentication of WebAuthn credentials between the authenticator and the server. Browsers often serve this role.
  • Relying party: The FIDO2 definition of a relying party is the entity whose web application utilizes the Web Authentication API to register and authenticate users.

Next we have the concept of Authenticator Attestation Global Unique Identifiers (AAGUID). An AAGUID is a unique identifier that the WebAuthn authenticators can choose to share with the relying parties (server) via clients (browsers). Even though it is critical to identify the authenticator, no central authority assigns the  AAGUIDs. Even if the AAGUID is available, it is merely a signal if the authenticator does not provide a verifiable attestation.

On the one hand, WebAuthn is designed with solid principles for user privacy; on the other hand, for enterprises, it is critical from a security perspective to validate that the users are identified correctly or  the type of authenticator being used can be validated. A lot of WebAuthn authenticators choose not to identify themselves by providing a generic AAGUID: AAAAAAAAAAAAAAAAAAAAAA. Adding a little fun to the situation would be the fact that Chrome on MacOS is a different authenticator from Safari on MacOS. If a user has enrolled themselves on Chrome on MacOS, they cannot use Safari to authenticate themself with that enrollment, which could be confusing to most users. Nevertheless, none of them provides a verifiable attestation to prove the assurance of the authenticator. Windows Hello, on the other hand, does provide an AAGUID with verifiable attestation. In a nutshell, even though platform authenticators like MacOS Touch ID provide ease of use, they cannot be verified on the server side because of the lack of verifiable attestation.

Allow list feature

At Okta, we recognize that many organizations have substantial requirements for the provenance of an authenticator. We recently released a feature named allow list that allows organizations to select the authenticators (AAGUIDs) they trust from the FIDO Metadata Service (MDS) list. This feature allows the organization administrators to lock down the WebAuthn enrollments and authentication with their choice of authenticators. 

So far, we have seen how WebAuthn is one of the Authenticators whose adoption has picked up in recent years with its ease of use and phishing-resistant characteristics. Additionally, we looked upon some of the concepts and challenges that come along with the territory and how, at Okta, we are trying to solve them for our customers. 

Have questions about this blog post? Reach out to us at [email protected].
Explore more insightful Engineering Blogs from Okta to expand your knowledge.
Ready to join our passionate team of exceptional engineers? Visit our career page.
Unlock the potential of modern and sophisticated identity management for your organization. Contact Sales for more information.
You can learn more about WebAuthn by testing out our tool webauthn.me.