In this article, you’ll get an overview of the motivations behind the FIDO2 (Fast Identity Online) effort and how it works, a walk through of some popular use cases, who the players are behind the specification, and finally, where FIDO2 is headed.

State of Affairs

Passwords are real problem. They’re hard to remember and they need to be changed frequently. In short, they can be clumsy.  As a result, the vast majority of breaches are due to poor handling of passwords. Even outside the scope of authentication, unacceptably high abandonment rates are commonplace because users are hesitant to supply a password.

To put all this is perspective, check out the graphic below depicting the seriousness of user data breaches.

Enter FIDO2

FIDO2 is a FIDO Alliance effort comprised of the W3C Web Authentication API (WebAuthn) and FIDO Alliance’s Client-to-Authenticator Protocol (CTAP). Altogether, FIDO2 enables users to leverage common devices to authenticate to online services from both mobile and desktop environments (3). More on these standards below.  

FIDO2 gives users strong hardware-based authentication via these public keys, thereby, foregoing reliance on weak password-based methods. Another important feature is origin checking to prevent phishing attacks.

Login using a FIDO-2 enabled hardware key enables multiple choices for user authentication including:

  • Single factor passwordless authentication
  • Two-factor authentication (2FA)
  • Multi-factor authentication (MFA)

Ok, I get FIDO2 but what about FIDO1?

Actually, there is no “FIDO1,” but instead, FIDO U2F (Universal 2nd Factor).  FIDO2 is the latest generation of the U2F protocol that notably adds passwordless authentication capability. FIDO2 is backwards compatible with FIDO U2F and will likely subsume it in the near future.

Some Use Cases

Before I go into detail about the FIDO2 specification let’s set some context with use cases. The application of FIDO2 are vast, but for the purpose of this article I’ll introduce a few common use cases.

Terms to Remember

Before jumping into the use cases let’s define key terms.  Below is a list of prominent specification concepts that will be referenced in the following use cases.

  • Authenticator – A cryptographic entity used by a WebAuthn Client (e.g. browser) to generate a public key credential and register it with a Relying Party, and then authenticate by potentially verifying the user, and then cryptographically signing and returning, in the form of an Authentication Assertion, a challenge and other data presented by a WebAuthn Relying Party (in concert with the WebAuthn Client) (2).

In the FIDO2 Architecture diagram above, OPTION 1 and OPTION 2 represent types of authenticators. Some practical authenticator examples include Yubico Yubikey, Thetis BLE U2F Security Key and Biometric facial and fingerprint recognition.

Sample Authenticators

  • Ceremony – The concept of a ceremony is an extension of the concept of a network protocol, with human nodes alongside computer nodes and with communication links that include user interface(s), human-to-human communication, and transfers of physical objects that carry data. What is out-of-band to a protocol is in-band to a ceremony. In this specification, Registration and Authentication are ceremonies, and an authorization gesture is often a component of those ceremonies. (2)
  • WebAuthn Client – An intermediary entity typically implemented in the user agent (in whole, or in part). Conceptually, it underlies the Web Authentication API and embodies the implementation of the Create and DiscoverFromExternalSource internal methods . It is responsible for both marshaling the inputs for the underlying authenticator operations, and for returning the results of the latter operations to the Web Authentication API’s callers (2).  

The following screenshots represents a sample usages of the WebAuthn Client API demonstrating the ability for a user to register a new authenticator.  Please note that Chrome and Firefox’s implementation and handling of device discovery are slightly different. Most notably, Firefox does not support Trusted Platform Module (TPM).  In short, Firefox is not recognizing fingerprint biometrics on my Macbook but Chrome is.



  • Client Device – The hardware device on which the WebAuthn Client runs, for example, a smartphone, a laptop computer or a desktop computer, and the operating system running on that hardware. (2)  

NOTE: In recent news, Google announced that Android has added certified support for the FIDO2 standard. See Big Players below.

  • Relying Party (RP) – The service whose web application or native application utilizes the Web Authentication API to register and authenticate users.  

NOTE:  While the Relying Party term is used in other contexts (OAuth, X.509, OpenID Connect, SAML, etc), an entity acting as a Relying Partner in one context is not necessarily a Relying Party in other contexts.

  • Attestation – Generally, Attestation is a statement serving to bear witness, confirm, or authenticate. In the WebAuthn context, attestation is employed to attest to the provenance of an authenticator and the data it emits (2).
  • Authorization Gesture – An authorization gesture is a physical interaction performed by a user with an authenticator as part of a ceremony, such as registration or authentication. By making such an authorization gesture, a user provides consent for a ceremony to proceed. This may involve user verification if the employed authenticator is capable, or it may involve a simple test of user presence (2).

Note: In the sample use cases below, “the website” refers to a Relying Partner (RP) whose website supports FIDO2 web authentication.


  1. Sylvie navigates to the website on her phone (Client Device) and signs into an existing account  
  2. The phone prompts the user, “Do you want to register this device with this service?”  
  3. Sylvie agrees, the browser (WebAuthn client) initiates the Ceremony, and Sylvie is prompted for a previously configured authorization gesture such as a roaming security key authenticator, resident authenticator (fingerprint, facial recognition, etc.)
  4. The website confirms completed registration


  1. On her laptop (Client Device), Sylvie has paired her phone through Bluetooth  
  2. She then navigates to the website and starts the login process  
  3. The website presents a message, “Please complete sign-in on your phone”  
  4. On her phone a prompt or notification is presented, “Sign in to XYZ”
  5. Still on her phone, Sylvie selects prompt or notification and is presented with a list of XYZ identities, e.g., “Sign in as Sylvie”  
  6. Sylvie selects her identity from list and provides the associated authorization gesture  
  7. Now, Sylvie is back on her laptop and sees that the website has logged her in

New Device Registration

This use case scenario illustrates how a Relying Party can leverage a combination of a roaming

authenticator and a platform authenticator such that the user has: a “primary” roaming authenticator that they use to authenticate on new-to-them client devices.

Note: This approach of registering multiple authenticators for an account is also useful in account recovery use cases.

  1. Sylvie goes to her laptop that does not have a platform authenticator
  2. Sylvie navigates to the website in a browser (WebAuthn client) and signs in to an existing account using whatever method they have been using (possibly a legacy method such as a password), or creates a new account
  3. Sylvie navigates to account security settings and selects “Register security key”
  4. The website begin the ceremony and prompts her to plug in a USB security key fob and Sylvie does so
  5. The USB security key blinks to indicate she should press the button on it; she does by supplying the authorization gesture
  6. Website shows message, “Registration complete.”
  7. Note: Since this computer lacks a platform authenticator, the website may require the user to present their USB security key from time to time or each time the user interacts with the website. This is at the website’s discretion.
  8. Later, on her laptop, which features a fingerprint platform authenticator, Sylvie navigates to the website in a browser and initiates sign-in
  9. Website initiates the ceremony by prompting her to plug in their USB security key
  10. Sylvie plugs in the previously registered USB security key and performs the authorization gesture
  11. Website shows that she is signed in, and navigates to the signed-in page
  12. Website prompts, “Do you want to register this computer with the website?” and Sylvie agrees
  13. Laptop prompts Sylvie for a previously configured authorization gesture and she provides this.
  14. Website shows message, “Registration complete.” and Sylvie signs out of the the website
  15. Later, again on her laptop, she navigates to the website in a browser and initiates sign-in
  16. Website shows message, “Please follow your computer’s prompts to complete sign in.”
  17. Laptop prompts her for an authorization gesture and she provides this.
  18. Website shows that Sylvie is signed in, and navigates to the signed-in page.

Taste of the Specification

Now that we have a better overall picture of what is possible with FIDO2, let’s take a deeper look at the components that make up the FIDO-2 standard:  WebAuthn and CTAP.


WebAuthn is an open standard specification that defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of user authentication. It was officially ratified by the W3C (World Wide Web Consortium) in April 2019. WebAuthn is supported in the Chrome, Firefox, Edge, and Safari Technology Preview browsers to different degrees, but support for credential creation and assertion using a U2F Token, like those provided by Yubico (see Sample Authenticators image), is supported by all of them.

WebAuthn specifies the API for registering credentials and subsequent use of these credentials for authentication. The credentials belong to the user and are managed by an authenticator, with which the WebAuthn Relying Party interacts through the client platform. Relying Party scripts can (with the user’s consent) request the browser to create a new credential for future use by the Relying Party. See figure, Registration Flow below (1).

Registration Flow

Clients can also request the user’s permission to perform authentication operations with an existing credential. See figure, Authentication Flow, below (1).

Authentication Flow


The CTAP protocol defines the messaging protocols between an external device, like a phone or FIDO-compliant key, and a WebAuthn compliant web browser.

This protocol is specified in three parts (8):

  • Authenticator API: At this level of abstraction, each authenticator operation is defined similarly to an API call – it accepts input parameters and returns either an output or error code. Note that this API level is conceptual and does not represent actual APIs. The actual APIs will be provided by each implementing platform.
  • Message Encoding: In order to invoke a method in the authenticator API, the host must construct and encode a request and send it to the authenticator over the chosen transport protocol. The authenticator will then process the request and return an encoded response.
  • Transport-specific Binding: Requests and responses are conveyed to roaming authenticators over specific transports (e.g., USB, NFC, Bluetooth). For each transport technology, message bindings are specified for this protocol.

The Big Players


The recent announcement of Google’s support of FIDO2 on all new Android device (1) is just what the doctor ordered for wide-spread adoption of FIDO Alliance’s next generation version, FIDO2. This shouldn’t come as a surprise due to Google’s heavy involvement in defining the specification (3).  

Why is this such a big deal?  Well, any compatible device running Android 7.0+ is FIDO2 capable out of the box.  Users are not required to install additional apps and developers can add FIDO authentication to their applications using a simple API. This leads to expedited adoption of FIDO2.


In November 2018, Microsoft announced (2) that authentication to their online services support sign-in with a FIDO2 compliant device. Again, no surprise here. Microsoft is a key player in the FIDO2 Technology Working Group (3). In July 2018, Microsoft Edge browser announced support (4) for FIDO2, which allows users to authenticate with a removable device and Windows Hello biometrics or PIN.


Apple is trailing Google and Apple, but has jumped into the game, starting with Safari Technology Preview release 71 support for USB-based authenticators.

Big Browser Support

  • Chrome
  • Firefox
  • Microsoft Edge
  • Safari Technology Preview

Oh no, where’s my key?

In the event that a user loses their security key, or is stolen, a hacker may be able to compromise their account and cause major headaches. However, the severity of damage depends on how the site has implemented authentication, especially in the case of passwordless authentication. Some important questions are:

  • Does the website offer an alternative method that allows a user to access their account to delete the key?
  • Does the website offer an account recovery process?
  • Did the website require the user to enter a PIN when registering their key?


With the increased adoption of industry leaders and the ever-increasing threat of brute-force attacks, a change in how we deal with passwords is necessary. Will FIDO2  become a widespread solution? First, the price of external authenticators must become more affordable to the masses.  Currently, keys start at $20. I believe many relying parties will offer keys for free, especially intranet-based services. What remains to be seen is how the industry responds to this new standard and more importantly, how hungry developers are to adopt it.

Leave a comment

Your email address will not be published. Required fields are marked *