Use case: FIDO passkey registration self-service
This article explains how a logged-in end-user can register FIDO Authenticator (a passkey) with the Airlock IAM account.
End-users need to be authenticated for the protected self-registration process.
To register FIDO Authenticators (passkey) during the login process, see Use case: FIDO token migration self-service instead.
Note that FIDO passkeys can be managed by administrators in the IAM Adminapp, but they can only be registered by the end-user in a self-service.
Goal
- Understand how the FIDO passkey registration self-service works.
- Learn details about the prerequisites and limitations of FIDO registration.
All following procedures are exemplary and will vary according to your setup or needs.
Initial thoughts
The FIDO passkey registration is part of the Loginapp REST API and its web UI. The registration process is implemented as a protected self-service flow. It allows great flexibility in combining the passkey registration with other steps and for any authorization and access conditions.
Great care should be taken especially regarding authorization and access conditions:
If FIDO passkeys are used for strong authentication, it is mandatory to authenticate the end-user in a strong way before FIDO registration, because the authenticity of the registered FIDO passkey is based on the security prevalent during the registration self-service.
While it is possible to enroll FIDO passkeys just based on username and password, the security risks of such a setup must be considered thoroughly.
Thus, we strongly recommended protecting the FIDO passkey registration self-service flow with an access condition that guarantees sufficient end-user authentication. This is especially useful if different levels of authentication are allowed (or might be configured in the future).
In all cases, Airlock IAM acts as FIDO relying party.
Prerequisites
- An end-user account exists in IAM and end-users can be authenticated (e.g. username, password, and a 2nd factor).
- The end-user has a supported FIDO passkey.
- The FIDO passkey complies with the settings in the FIDO configuration.
- The end-user's browser or mobile app supports FIDO.
- To support FIDO passwordless authentication (now or in the future), make sure to require keys to be resident during the registration.
- A protected self-service flow to register FIDO authenticators has been configured.
- The FIDO registration flow's configured access condition is fulfilled.
- The end-user is authorized to register FIDO passkeys (i.e., the FIDO registration flow's configured authorization condition is fulfilled).
Passkey registration
The following flow chart shows how the FIDO registration step can be used:
- (1)
The end-user is strongly authenticated with existing credentials and usually an established second factor. This may be another FIDO authenticator or a different second factor.
- (2)
The end-user starts the FIDO registration self-service flow. This may be for example by clicking on a link or pressing a button in an app.
Airlock IAM verifies that:
- the user is authenticated.
- the configured access condition is fulfilled.
- the configured authorization condition is fulfilled.
- (3)
The end-user has to choose a display name for the registered FIDO Authenticator. The display name later helps the end-user (or the helpdesk) to identify the authenticator – this is especially important if a user registers multiple authenticators.
See below for an alternative way to determine the display name.
- (4)
IAM sends a FIDO registration challenge to the FIDO client (browser or mobile app).
The challenge and a set of constraints for accepted FIDO Authenticators are sent to the FIDO client. The constraints depend on the FIDO settings in the configuration.
They include:
- Signature algorithm constraints.
- List of excluded FIDO Authenticators (e.g. already registered ones).
- User verification preferences.
- Type of authenticator (platform or cross-platform).
- Whether FIDO passwordless must be supported.
- FIDO attestation preferences.
- (5)
The browser 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 passkeys are available to the FIDO client, a selection dialog is presented to the end-user.
- (5)
Airlock IAM verifies the response to the challenge and checks whether all FIDO Authenticator constraints are met. The verification details depend on the FIDO configuration settings in Airlock IAM.
If the verification succeeds, the FIDO credential is stored in the IAM user database and a confirmation is sent to the caller.
Arbitrary other steps may be added before and/or after the FIDO registration step in the self-service flow.
You may, for example, add another 2nd factor (e.g. Airlock 2FA) to further secure the FIDO registration flow.
Auto-generate display name during FIDO passkey registration
IAM can automatically generate a display name based on the AAGUID of the passkey.
See FIDO Settings >> Auto Generate Display Name for further information. If enabled, the user is not asked to enter the display name before passkey registering a passkey.
It is best combined with the FIDO Credential Display Name Change Step after the registration step to allow the end user to edit the generated display name.
Limitations
The following limitations apply in FIDO token migration.
- FIDO is only supported by the Login UI and the Loginapp REST API
- FIDO passkeys 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.
- Not all FIDO Attestation statement formats are supported by Airlock IAM. Please review the set of supported formats in the documentation of the FIDO attestation verifying plugin in the FIDO settings.
- There are no end-user self-services to list or edit registered FIDO passkeys. The only protected self-service is the one to register new FIDO authenticators. Registered FIDO passkeys can only be managed using the IAM Adminapp (or its Adminapp REST API).