In these times of separation and remote working for all, our reliance on mobile and handheld devices for staying in touch has never been more important. As device use continues to evolve, the role of biometrics for authentication is also becoming increasingly commonplace.

Identifying the user with a fingerprint, face, or voice brings security benefits and improves user experiences. This coupling has been reinforced by regulations such as technical standards for Strong Customer Authentication within PSD2, which includes “Inherence” as an acceptable factor in how we authenticate.

Biometrics has become the cornerstone of many applications and will be critical in the future digital economy. Yet, not many global open standards exist for biometric authentication, and historically, biometric data has been tied to specific operating systems or applications.

In this post, we take a look at the FIDO2 project and Web Authentication standard (WebAuthn) — emerging open standards that have the potential to significantly change how proofs of biometric authentication are elicited. We’ll look at how the standards work, what improvements they offer, and how this might improve existing biometric approaches.

What are FIDO2 and WebAuthn?

As you may have guessed, FIDO2 isn’t the second version of someone’s favorite dog. The FIDO (Fast IDentity Online) Alliance is an organization whose mission is to eradicate passwords in favor of stronger forms of authentication. FIDO created the FIDO2 Project, which utilizes two new specifications:

• The Web Authentication (WebAuthn) specification, which is defined by W3C and enables the use of FIDO authentication through a standard API implemented in browsers.
• The Client To Authenticator Protocol (CTAP) which allows external devices such as cellphones to work with browsers supporting WebAuthn.

Webauthn.io provides many resources for demoing and implementing the WebAuthn spec.

These standards intend to make passwordless authentication a reality by extending the use cases offered by existing FIDO protocols like U2F and UAF. Why passwordless? Well, the benefits are pretty obvious; giving up secret credentials is at the heart of most phishing attacks. Credentials only accessible with a user biometric on a user’s device is inherently more secure. Through the use of cryptographic credentials — and an architecture that supports the separation of concerns and scalability — defeating phishing is at the heart of what FIDO2 sets out to accomplish.

Biometrics as an authentication factor has obviously been available for some time and is an important feature of mobile operating systems. Apps can delegate authentication to the platform, allowing users to benefit from a better experience by authenticating using the built-in biometric credentials. An important feature of WebAuthn is that it decouples this from the mobile operating system. Rather than relying on that delegation’s result — typically through a boolean style response — the protocol defines the means for providing cryptographically-asserted strong proofs-of-authentication that can be verified by a relying party while keeping the underlying biometric record highly secure. This means WebAuthn allows for a much greater degree of portability, with the same proofs-of-authentication supported on desktops with a biometric input device and across devices through CTAP.

All fine-and-dandy one might say, but this is just a specification. Who’s actually implementing it? Well, here comes the interesting point: Google, Apple, Microsoft, and many other technology giants are part of the FIDO Alliance. With support for the iPhone and iPad as an Authenticator in iOS 14, WebAuthn is getting ready for the big time. Still, the specification will continue to evolve — the “Level 2” standard is still at a Working Draft stage, and according to the proposed certification levels they’ll be specifications up to 3+. Nevertheless, the base Level 1 is there and being backed up by real-world implementations.

How It Works

The number of participants in the FIDO Alliance intimates that there are several moving parts in how WebAuthn works. The process for eliciting a biometric gesture and receiving the resultant proofs-of-authentication is based on several components:

• WebAuthn Relying Party: The WebAuthn Relying Party (WRP) is the entity relying on the proofs-of-authentication created by the Authenticator when the user provides their biometric gesture. The WRP will implement both a Client in JavaScript at a given domain, to which a credential is bound, and a Server responsible for verifying the proofs-of-authentication and anything else that is deemed “secure.”
• WebAuthn API: This is implemented in the browser and provides access to the underlying biometric capabilities of either the local or a remote device, called the Authenticator.
• Authenticator: This device holds the private key bound to a given credential and is responsible for prompting the user to provide their biometric gesture. It can be a phone, tablet, or USB device that has gone through FIDO certification and can be accessed “on platform” or via CTAP over Bluetooth or NFC.
• Human being (aka The User): The user of a given application and holder of the biometric gesture that interacts with the Authenticator.

While there are some idiosyncrasies dependent on the combination of components and how the WRPs implement their software, they work together to elicit a biometric gesture from the human being. The process involves a number of steps:

Note the diagram and description are intended to be a general outline and do not describe the sequence in explicit, exacting detail.

1. Map Human to Biometric Credential. The user browses to a website that requires authentication, which is hosted by the WRP at a given domain. They have previously created a credential at this domain, and this credential is bound to it — it can only be used here.
2. Make Web Authn Request: Depending on WRP and behaviors supported at the Authenticator (specifically a feature called Resident Keys), either a credential is requested by the WRP, or the Authenticator can detect the credentials that work for the domain. The authentication request is made at the WebAuthn API using the navigator.credentials.get method. The request includes a randomized challenge generated by the WRP on their server.
3. Prompt User for Gesture: On invoking the API, the Authenticator takes over and prompts the user for the biometric gesture allied to the credential bound to the WRP.
4. Verify Authentication Assertion: The user responds, upon which the Authenticator creates an Authentication Assertion. This Assertion includes several attributes describing the authentication event, which is signed using the private key allied to the credential. The Authenticator responds to the WebAuthn API, which returns the response to the WRP, who can then verify the signature. This verification typically happens on the WRP’s FIDO Server in a sufficiently secure context, away from prying eyes in the browser.
5. On Your Way, Citizen: With the user duly authenticated, the WRP can provide privileged content to the user.

These steps show the significant levels of decoupling in the specification. It means that, with appropriate certification by FIDO, the components can be provisioned across ubiquitous applications and devices. All significant browsers now have support in some form for the WebAuthn API, and all the major platform providers such as Android, iOS, and Windows Hello function as Authenticators. This availability is likely to generate some very interesting use cases. As an example, we’ll look at Device Authorization.

FIDO2 In The Real World: Device Authorization

Device authorization is a real-world scenario where WebAuthn could provide some significant value. It’s an activity that consumers perform frequently; for example, buy a new TV, Fire TV Stick or Chromecast, install some apps, and at some point, authenticate to login to Plex, Netflix, Disney+ or whatever your favorite app for streaming is.

The mechanism for authenticating varies depending on the app, but they frequently use a vanity URL and one-time passcode to login from a more capable device with a browser (to avoid password login via a TV remote, for example). There have been attempts to formalize this approach through the Device Authorization Grant under OAuth 2.0. But, as the draft specification itself notes, there are various security considerations, such as remote phishing, that need to be considered when implementing this grant type.

One way of improving security would be to add a standardized authentication step. But what if that authentication was based on WebAuthn, where the app provider allows the user to authenticate biometrically? In this scenario:

• On installation, the application displays a QR Code that the user scans using their cellphone.
• The QR Code is encoded with a URL that directs the user to the application website, which is the WRP. The user has previously registered their biometric — with their cellphone as their Authenticator — at the WRP.
• The user provides their biometric gesture, which is verified by the WRP.
• At the backend, the WRP signals to the application (either through a webhook or via polling from the application) that installation can complete. Finally, the user’s home page, with all their preferences, is displayed.

There are several notable advantages to this approach:

• It’s highly resistant to phishing attacks, meaning only persons authorized to access the account can log in and permit installation.
• It’s excellent for enforcing parental controls — no more kids installing apps after finding out mum or dad’s “secret” password.
• WebAuthn enables a smooth user experience without the need for a companion app to be installed on the trusted device but with sufficient friction for the human being to trust what’s going on. Visit the URL on your cellphone (which is also your Authenticator) — either typed in or via a QR code as the standard suggests — and simply present your biometric gesture to authorize the installation.
• The WebAuthn implementation itself also improves the security of the handoff between the app provider and the target platform. For example, the app can provide strong proofs-of-authentication to the platform, allowing the platform to become an enforcement point and providing for strength-in-depth. This could be done natively using the highly-compact CBOR-encoded Authentication Assertion or wrapping the proofs in a protocol like OpenID Connect that is geared towards the federation of identity.

WebAuthn, in this context, can therefore provide both stronger authentication factors and proofs-of-authentication to support an improved user experience that is only inhibited in a positive manner. It also provides a basis for further enhancements — for example, for doing in-app payment authorization — that can provide significant value in the future.

Final Thoughts

Biometrics plays a significant role in how applications are being engineered, already reflected in the ubiquity of fingerprint or face-recognition authentication methods used across the mobile app economy. As this technology improves, the role of biometrics will only become more significant.

However, in a connected world built on open standards and APIs, communicating proof that biometric authentication has taken place, without compromising the biometric data itself, will become critical to building secure, distributed systems.

While FIDO2 helps with the proofs-of-authentication for the biometric event, over time, the community should look to bring it together with other standards like OpenID Connect. For example, this could be accomplished with a profile that defines standard ID Token claims representing the Authentication Assertion properties.

Moreover, the FIDO Alliance is also extremely focused on demonstrating the benefits to user experience WebAuthn can offer. It has created a Github repository dedicated to highlighting the key features. Integrations between standards and a focus on how to authenticate biometrically can only serve to strengthen proofs-of-authentication and help platform providers build secure solutions that deliver a great user experience for real human beings.