In this first article we will take a high-level look at FIDO 2.0 (Fast Identity Online) and WebAuthn (Web Authentication). For a more in-depth look at working with FIDO and the WebAuthn API, check out this blog.

FIDO’s vision is to replace passwords and many other authentication methods, using a FIDO authenticator as the primary way you verify your identity to web applications.

FIDO authenticators come in many different form factors. Some authenticators are embedded inside your client device (e.g. secure elements in mobile devices or TPMs in computing devices). Other authenticators are connected to your client device with USB, NFC or Bluetooth. Many connected authenticators are small dongles the size of a USB memory stick, but it’s also possible to use Bluetooth or other wireless connections to access an authenticator embedded inside another device, such as your phone.

What are the FIDO & WebAuthn Standards?

The FIDO Alliance is working to standardise all of this and to enable interoperability across different client devices, operating systems, web browsers, web applications and online services.

The FIDO family of standards is roughly divided into two main areas; FIDO specifications and W3C WebAuthn. The FIDO specifications are aimed at the smaller audience of vendors of authenticators, web browsers and operating systems. On the other hand, W3C WebAuthn is aimed at the larger audience of developers of web applications and online services. There are of course some generic specifications, such as FIDO Security Reference, that are very relevant to both audiences.

Notably, FIDO has a history starting in around 2012 with several versions of the specifications being published over time. The current version is FIDO 2.0, which is the version that introduced WebAuthn. FIDO 2.0 entered the final stages of standardisation in 2018.

What are FIDO authenticator types?

FIDO authenticator types have a number of key characteristics, known as dimensions in FIDO terminology:

  • Authenticator attachment
  • Credential storage
  • Authentication factors

Authenticator attachment

Two types of attachment are defined: platform and portable.

Platform authenticators are embedded and physically bound to the client device. The intention is that you cannot remove it from one client device and connect to some other client device, for example the TPM on the motherboard of your laptop.

These kinds of authenticators are highly convenient. There is no need to remember and keep any additional devices with you, and authorisation is often implemented with biometric recognition such as a fingerprint reader. The obvious downside is that if you want to access web applications with another client device, then you need to register another authenticator.

Portable authenticators are typically small dongles that you can choose to keep with you. This kind of authenticator needs to be connected to your client device when you want to authenticate to a web application. Authorisation with a portable authenticator is often very simple and requires only presence of the authenticator without any pin code, biometric recognition or another factor.

Credential storage

FIDO authenticators store secret keys in one of two ways: client-side storage and server-side storage.

With client-side storage, secret keys are embedded in the authenticator and are typically not exportable in any format.

With server-side storage, any secret keys are generated by the authenticator and then exported and stored in encrypted format on the server side. The keys are encrypted in such a way that only the authenticator that encrypted the key can decrypt it.

The benefit of client-side storage is that no server-side lookup is required before authenticating. To authenticate with a server-side authenticator, you first need to give your username so that the server can look up your encrypted key that is required for authenticating.

The downside of client-side storage is limited capacity. There may be a limit on the number of secret keys you can store on such an authenticator. Server-side storage on the other hand has effectively unlimited capacity.

Some authenticators that support both storage models do exist.

Authentication factors

The FIDO authenticator itself is always one authentication factor: something you have. The other authentication factors are something you know and something you are. Examples of these are PIN codes and biometric recognition.

Two types of authorisation are defined: test of user presence and user verification.

Test of user presence requires a single authentication factor only, which with FIDO is the ‘something you have’ factor. This authorisation gesture is often very simple, such as touching the authenticator or plugging the authenticator into a USB port.

User verification requires one or more additional authentication factors. Authorisation with this kind of authenticator typically requires having the FIDO authenticator present and, in addition, entering a PIN code or doing a fingerprint scan for biometric recognition.

Working with a FIDO authenticator

When it comes to working with a FIDO authenticator, there are two main use cases to consider: registration and authentication.

Registration

Registration is when you put your FIDO authenticator to use in a web application. There needs to be a function in the web application that guides you into this process.

Registration starts with discovery, where you are presented with a menu of FIDO authenticators that are connected to your client device. In many cases there will be only one and discovery is bypassed.

After choosing an authenticator you are prompted for an authorisation gesture as consent for registration. Internally, the FIDO authenticator generates a new key pair that is scoped to the web application and returns the public key to the web application.

The web application then needs to store the generated key as a credential in your user profile.

Authentication

Authentication with a FIDO authenticator follows the common asymmetric crypto authentication protocol; the server generates a challenge that the FIDO authenticator signs with the key generated during registration. The signature is passed back to the server where the signature is validated, with the public key stored with your user profile.

Authentication generally begins in one of two ways:

  • The application asks for authentication by any previously registered FIDO authenticator.
  • The application first asks for a user identifier, then looks up registered FIDO authenticators for that user and asks for authentication by any of those authenticators.

The first process is only possible with authenticators that implement client-side storage of credentials. A downside of the second process is that it may appear less user-friendly, as there is an extra step of asking for a user identifier. For improved user experience, the browser’s local storage could be used to remember choices made by the user.

If there is more than one authenticator available, then discovery is needed where you are asked to make a choice from matching authenticators.

After choosing an authenticator, you are prompted for an authorisation gesture as consent for authentication. Internally, the FIDO authenticator signs a server-generated challenge with its private key and returns the signature for validation on the server.

What is FIDO User Identity?

There is no universal FIDO identity or FIDO user identifier. A FIDO identifier is essentially a public key, which is generated per authenticator and scoped per web application. It is important to note that FIDO provides only authentication; there are no user attributes of any kind.

The scoping per web application (relying party) of the key pair is tightly defined:

  • A single FIDO authenticator presents different identifiers for different web applications.
  • Two distinct FIDO authenticators will never present identical identifiers.

The web applications and online services will need to keep track of the FIDO identifier. It is the responsibility of the application to associate these FIDO identifiers with real-world identities/attributes, such as email address. Also, the application must be able to associate multiple FIDO identifiers per user to allow users to register multiple authenticators.

Conclusions

Is FIDO up to delivering a replacement for passwords? Personally, I hope so. There really are not that many alternatives with the same level of security and cross-platform interoperability. Sure, replacing passwords will not be an easy task as FIDO is very different (from both end-user and developer perspectives) to authentication with simple usernames and passwords.

There is also still some variance in exactly which authenticator types are supported by different browsers and client devices. Eventually, most interoperability issues should be sorted as, for example, browser vendors are working on completing their implementations of FIDO and WebAuthn.

In conclusion, we need early adopters who are willing to test how things work and share their experiences so that the user experience for end users can evolve into something that is as easy as usernames and passwords.

Next steps: Take a detailed look at working with FIDO and the WebAuthn API.