This article explains on a conceptual level how to authenticate end-users using FIDO passwordless as the sole factor (no username, no password). It also provides information relevant for correct use and configuration.
Goal
- Understand passwordless 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
End-user authentication with FIDO authenticators/passkeys can be done in several ways. One of them is using FIDO passwordless, i.e. FIDO as the sole authentication factor. In this scenario, the end-user does not have to enter a username or password but only uses the FIDO authenticator.
Note that FIDO can also be used as the second factor in an authentication flow. This does not necessarily imply that the end-user has to enter a password.
How to use FIDO as the second authentication step is described separately.
In all cases, Airlock IAM acts as FIDO relying party.
Prerequisites
- An end-user account exists in IAM.
- The end-user has FIDO enabled as a possible authentication method.
- The FIDO authenticator has been registered as a resident key. This is guaranteed if the FIDO configuration setting Require resident keys was enabled during the registration.
- The end-user has a supported FIDO authenticator capable of storing resident keys.
- The FIDO authenticator complies with the settings in the FIDO configuration.
- The end-users browser or mobile app supports FIDO passwordless (i.e. support CTAP2).
- The FIDO authenticator has been registered with the end-users account.
FIDO passwordless authentication flow
The following flow chart shows how FIDO passwordless works with Airlock IAM:
(1) | The browser or mobile app initiates the authentication process. This may be done by trying to access a protected resource or by calling the FIDO passwordless REST API directly. | |
(2) | IAM creates a FIDO challenge. At this stage, the end-user to be authenticated is not yet known. | |
(3) | IAM sends a challenge together with end-user verification preferences to the FIDO client (browser or mobile app). | |
(4) | The browser interacts with the end-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) | From the response from the FIDO authenticator, Airlock IAM can determine the end-user to be authenticated and check whether the response is valid for the used FIDO credential. 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 passwordless in an authentication flow.
- FIDO is only supported by the Loginapp UI and the Loginapp REST API.
- FIDO authenticators must support resident keys for (later) passwordless authentication. This can be enforced during FIDO registration (token migration and self-service) and enabled in the FIDO settings in the IAM configuration.
- FIDO authenticators that have not been registered as resident keys need to be re-registered to use FIDO passwordless.
- Not all browsers or mobile apps support passwordless authentication with FIDO.
- The FIDO passwordless end-user experience varies between web browsers when multiple resident FIDO credentials can be used for FIDO authentication. In this case, there is a menu from the web-browser requiring the end-user to select the correct FIDO authenticator. The menu cannot be customized or influenced.