FIDO2

Introduction

FIDO2 is a set of standards and technologies that promise to offer interoperable strong authentication, based on PKI, for both web and application clients (including native mobile clients). When FIDO2 authentication is used as a first factor, it can replace username and password authentication providing a strong, phishing resistant alternative which also offers an excellent end user experience. IBM Security Verify supports FIDO2 for authentication to its own web interfaces and for access to applications integrated via single sign-on. Adding passwordless authentication to your applications, without writing any code, is easily accomplished within Verify.

IBM Security Verify can also provide FIDO2 services directly to custom applications acting as FIDO2 Relying Parties. This more complex integration allows an application to maintain full control of the user experience.

Support and Adoption

FIDO2 relies on the end user having a FIDO2-capable authenticator. The good news, for adoption, is that many computers and phones now have FIDO2 platform authenticators built in. The Touch Bar on a Mac or the Windows Hello hardware on a PC can both act as FIDO2 authenticators. The latest iOS and Android devices natively support FIDO2 in conjunction with their biometric sensors.

FIDO2 also supports the concept of portable authenticators. These are small external "keys" which connect to a computer or phone via USB, Bluetooth, or NFC. These can have a built-in biometric sensor or they can user a PIN to verify the user.

Client-side application support is also needed for FIDO2. Again, there is good news. All the major browser vendors now support the WebAuthn (JavaScript) API which allows web applications to talk to FIDO2 authenticators.

📘

Browsers vs native applications

Native (non-browser) applications can also support FIDO2 authentication via platform SDKs but this article focuses on the use of FIDO2 when the client is a web browser.

Components

The FIDO2 standards describe a number of components. The following diagram shows these components in an architecture diagram for the WebAuthn use case.

You can see from the architecture diagram that IBM Security Verify acts as a FIDO2 Server. When using this to integrate FIDO2 authentication into a custom web application, the web application mediates FIDO2 messages between the browser's WebAuthn APIs and IBM Security Verify FIDO2 REST APIs.

Registration

In order to use the FIDO2 authentication method, a user must have previously registered a FIDO2 authenticator against their account.

Registration is performed by obtaining an attestation challenge from the FIDO2 Server and passing it to the WebAuthn API in the browser (using client-side JavaScript). At this point the browser takes control and manages the registration process with the authenticator. A response message from the authenticator is returned from the WebAuthn API which must be forwarded to the FIDO2 Server.

The FIDO2 Server validates the challenge response and associates the FIDO2 authenticator with the end user account. It returns a success message when this is complete.

Authentication

FIDO2 Authentication is performed by obtaining an assertion challenge from the FIDO2 Server and passing it to the WebAuthn API in the browser (using client-side JavaScript). At this point the browser takes control and manages the authentication process with the authenticator. A response message from the authenticator is returned from the WebAuthn API which must be forwarded to the FIDO2 Server.

The FIDO2 Server validates the challenge response and looks up the end user account associated with the validated authenticator. It returns a message containing the User UUID of the authenticated user.

Note that this is the internal Cloud Directory UUID of the user. A call to the SCIM interface is required to read user data associated with this user.

Metadata

FIDO2 device manufacturers can provide metadata for their devices. The use of metadata files is not required for FIDO2 but they do enable additional capabilities.

A metadata file contains information about a set of authenticators such as brand, device model, a brand image, and device capabilities. This can be used to display information to the end user about the authenticators they have registered.

A metadata file also contains a public certificate which can be used to validate attestation certificates presented by devices that are covered by the metadata. Limiting registration to devices that present an attestation certificate signed by a particular authority can be used to limit the FIDO2 authenticators that can be used with a Relying Party. This can be useful in a deployment where only company-approved keys are permitted for use.

💎

Jon Harry, IBM Security