Use case: FIDO as 2nd factor in IAM

This article explains on a conceptual level how to use FIDO as the 2nd factor for user authentication in Airlock IAM. It also provides information relevant for correct use and configuration.

Goal

  • Understand user authentication with FIDO in Airlock IAM.
  • Understand the interaction between involved components.
  • Learn details about prerequisites and limitations.

All following procedures are exemplary and will vary according to your setup or needs.

Initial thoughts

User authentication with FIDO authenticators can be done in several ways. One of them is using FIDO as the second factor in an authentication flow, i.e. after some first authentication step.

Typically, the first factor is a username and password check, but other types of first factor steps may be used, as long they determine the identity of the user being authenticated.

Even if the first authentication step does not necessarily involve a password check, FIDO can still be used as a second authentication factor.

  • Examples of first authentication steps without a password are:
  • OIDC/OAuth
  • SAML
  • Device Token authentication
  • SSO tickets
  • Username without password

How to use FIDO as the first and sole authentication step is described separately.

In all cases, Airlock IAM acts as FIDO relying party.

Prerequisites

  • An end-user account exists in IAM and has a first factor (e.g. username and password).
  • The end-user has FIDO enabled as a possible authentication method.
  • The end-user has a supported FIDO authenticator.
  • The FIDO authenticator complies with the settings in the FIDO configuration.
  • The end-users browser or mobile app supports FIDO.
  • The FIDO authenticator has been registered with the end-users account.

FIDO as 2nd-factor authentication flow

The following flow chart shows how FIDO as a 2nd factor works with IAM:

UC-FIDO-2nd-factor-with-IAM
(1)

The end-user is identified by IAM (e.g. by entering username and password in the browser).

(2)

IAM looks up the list of applicable FIDO credentials, i.e. the ones registered for the user and matching the FIDO relying party id.

(3)

IAM sends a challenge together with the list of applicable FIDO credentials and the user verification preferences to the FIDO client.

(4)

The FIDO client interacts with the user and the FIDO authenticator to retrieve the response to the challenge, and it sends the response back to Airlock IAM.

If multiple suitable FIDO authenticators are available to the FIDO client, a selection dialog is presented to the end-user.

(5)

Airlock IAM verifies the response from the FIDO authenticator.

Details of the verification depend on the FIDO configuration settings in Airlock IAM and may involve the verification of a FIDO attestation.

(6)

IAM automatically redirects the user's browser to the intended target application or service.

Limitations

The following limitations apply when using FIDO as the second factor in an authentication flow.

  • FIDO is only supported by the Loginapp REST UI and the Loginapp REST API (not by the Loginapp (JSP)).