How FIDO Makes Passwordless Authentication Possible

Solving the world’s password problem

FIDO stands for Fast IDentity Online, an open alliance founded in 2012 to solve the password problem. FIDO2 is directly relevant to passwordless authentication in Azure AD and Azure security. The technology behind FIDO2 is based on asymmetric cryptography. A private key and a public key each generate a key pair. The recipient’s public key can be exchanged at any time with communication partners to encrypt messages. To decrypt the message, the recipient’s private key is required; the recipient must keep it safe, as third parties could decrypt the message if they intercepted it.

Every FIDO2 authenticator stores an X.509 attestation certificate during manufacturing. Manufacturers etch the private key into the device, making it impossible to export or tamper with. Furthermore, the device undergoes cryptographic attestation. Although attackers may try to intercept a registration request and substitute their own, they cannot swap the generated public key because the attestation signature will not match.

This is the first part of a two-part blog post explaining the details of FIDO2. Part one covers:

• the basics of passwordless authentication,
• the components of FIDO2
• registration and authentication process in detail.

In addition, the second part focuses on planning, implementing, and auditing a FIDO2 deployment in Azure AD.

Components of FIDO2

Principle

Specifically, WebAuthn and the Client to Authenticator Protocol 2 ( CTAP2 ) are two important components of the FIDO2 architecture (Figure 2):

• WebAuthn is a platform-independent, browser-based JavaScript API within the W3C Web Standard. The API allows users to authenticate to Internet services without a password. It does this using asymmetric cryptography based on a public key method.

CTAP2 controls the communication between the client and the authenticator. For example, the client can be a computer with a web browser and the authenticator can be a mobile device. The CTAP2 host is part of the client, which communicates with the authenticator via the CTAP CBOR API.

As Figure 1 shows, the CTAP2 protocol communicates with any application that implements CTAP2. Therefore, passwordless login is not limited to Internet services. Indeed, you can also use it for standalone or domain-joined Windows 10 devices.

The components

Moreover, Figure 2 illustrates several other important components of FIDO2 that are worth understanding:

• The Platform Authenticator and Roaming Authenticator act as a secure entity embedded in or attached to the user’s end device.
• The FIDO Metadata Service (MDS) helps prove authenticator authenticity by periodically retrieving authenticator certificate chains. Manufacturers randomly generate and store an Authenticator Attestation Globally Unique ID (AAGUID), which identifies the Authenticator model.
• The WebAuthn client implements the WebAuthn API and consists of an operating system and a web browser. It acts as an interface between the authenticator and the relying party, enabling the WebAuthn API to handle authentication.
• The relying party consists of the web server and the FIDO server. As a single construct, it provides access to a secure resource. It accepts requests from the server or web application to register and authenticate users. No specific protocol governs communication between the server or web application and the relying party, though developers commonly implement it as a REST API. TLS secures all communication; otherwise, the WebAuthn API will not allow any communication.
• Relying party and authenticator certification can be granted by the FIDO Alliance. This validates product conformity and interoperability. Each product carries different security requirements, ranging from Level 1 to Level 3+. Importantly, all authenticators must satisfy at least Level 1 to obtain FIDO certification.

Registration

Definition

During registration, the relying party creates a user account. The user accesses the service via a WebAuthn client, transfers data from an authenticator, and deposits a public key with the relying party. After registration, the user can authenticate to the same service using that authenticator. Figure 3 illustrates this process.

The steps

To complete registration, follow these steps:

1. A user navigates to a WebAuthn-enabled service (e.g. outlook.com) in the web browser and makes an authentication request.
2. The relying party returns a response to the WebAuthn client. This consists of parameters that the WebAuthn client must fill in to register. For example, the relying party can specify which authenticator to use. Local authentication can consist of entering a PIN, biometric features such as a fingerprint, or confirmation by an NFC reader.
3. The WebAuthn client receives the relying party’s parameters and checks the available authenticators connected to the WebAuthn client. Notably, the relying party ID derives from the domain name. The domain name (Origin) must be encrypted by TLS and can only be accessed via https://. The relying party ID is only valid if it matches the relying party’s origin. Assuming that the login URL of an Internet service is https://login.example.com, the following relying party IDs are valid: login.example.com (default) and example.com. But not m.login.example.com and not only .com.
4. The authenticator verifies whether the Relying Party performs a user interaction before registration occurs. When registering with an Internet service, this generates a new asymmetric key pair. This key pair is not shared between Internet services. This key pair goes by the name identification key pair, or simply key pair (Figure 4).

Verification

The authenticator’s private key signs the newly created public key along with the relying party’s information, and the relying party stores this for later authentication. Moreover, the authenticator runs a signature counter that increments after each registration and sends the updated value to the relying party. This counter helps identify and reject cloned authenticators.

5. The new public key generated and signed in the previous step and other necessary attestations are returned to the WebAuthn client. It is important to note that the authenticator must perform some form of attestation before delivery to verify authenticity. Typically, attestation includes:
   • a public authentication key digitally signed by the private attestation key and a challenge,
   • along with a certificate or similar data that can confirm the relying party’s provenance information for the public key. Developers refer to this packaged element as an attestation object.
6. Among other things, the WebAuthn client returns the attestation object to the relying party so that they can verify the response.
7. The Relying Party stores the public key and verifies the attestation object data and any extensions. Authenticator validation can be performed by the relying party itself or by the FIDO metadata service. Once the registration process is complete, the user can authenticate without a password using the authenticator used.

Authentication

For authentication, a user proves their identity to the relying party through a WebAuthn client using an authenticator. Specifically, Figure 5 provides a step-by-step overview of this process:

1. When a user authenticates to a WebAuthn service, the client makes an authentication request to a relying party.
2. Next, the relying party receives the authentication request and returns options to the WebAuthn client. Similarly to registration, the relying party generates a new challenge, among other data. As much information as possible, also known as an authentication assertion, should be returned to the WebAuthn client. This limits the user’s choice of authentication methods. This depends on the data the authenticator stores.
3. Then, the WebAuthn client processes the options from step 2 and calls the authenticator. As a result, the authenticator receives the relying party’s ID parameters.
4. The authenticator receives data from the WebAuthn client and verifies that the relying party ID matches. It then generates an assertion signature using the private key. However, before doing so, it may require local re-authentication of the user.
5. Among other things, the authenticator returns the signed data of the assertion signature to the WebAuthn client.
6. The WebAuthn client sends the authenticator data and assertion signature to the relying party.
7. The Relying Party verifies the availability of the public key in the database. It also verifies the assertion signature with the public key (public identification key) stored during registration.

Summary and outlook

The FIDO2 standard and the W3C have significantly improved authentication security for Internet services and applications. The authenticator handles key management automatically, eliminating time-consuming administration. Additionally, the CTAP2 protocol supports both embedded and external authenticators via USB, NFC, and BLE interfaces, ensuring that the secret never leaves the authenticator.

However, the FIDO2 standard continues to evolve. As a result, new capabilities are emerging:

• Enterprise Attestation (EA) allows you to link a credential to an account using a persistent identifier. This is something you might be familiar with from smart cards. EA targets environments where a trusted relationship exists between devices and the relying party. The FIDO privacy standard requires that “a FIDO device not have a global identifier visible on websites.”
• CTAP 2.1 enables the management of resident keys on an authenticator. This means that you can
  • manage your PIN code,
  • display the credentials to be discovered,
  • add or remove fingerprints and reset the authenticator via a browser, operating system control panel, application, or CLI tool. In addition, CTAP 2.1 allows user verification to always be required on the authenticator, even if the relying party does not request it.

So, the next part of this two-part series will be about how to:

• to plan,
• to configure
• auditing passwordless authentication in Azure AD.

See also our Google Workspace vs Office 365 comparison.

Related Azure Tutorials

Continue exploring related Azure guides:

See also our Google Workspace vs Office 365 comparison.