Introduction to FIDO and passkeys

Airlock IAM’s FIDO implementation offers a range of configuration and usage options. This article provides an overview of the key FIDO concepts to help you make informed decisions when implementing FIDO with Airlock IAM.

For more information, see the links below.

FIDO distinguishes between roaming authenticators (e.g., hardware tokens such as USB security keys or Bluetooth devices) and platform authenticators (e.g., built-in fingerprint sensors or face recognition on laptops or smartphones). Roaming authenticators are portable and can be used across multiple devices, while platform authenticators are tied to a specific device, providing a seamless user experience.

Note that platform authenticators may synchronize keys across several devices. These so-called synced passkeys are therefore not strictly device-bound, but they significantly enhance the user experience, especially regarding key recovery.

The ability of authenticators to protect their private keys highly influences the overall security of the authentication process.

FIDO operates using a public-key challenge-response mechanism. During registration, the authenticator generates a new key pair and shares the public key with the relying party. During authentication, the server issues and sends a cryptographic challenge that the authenticator signs with its private key.

In both processes, the server domain is verified in a way that FIDO provides phishing-resistant authentication without transmitting secrets.

FIDO makes a distinction between user presence and user verification.

User presence simply confirms that a human is interacting with the authenticator (e.g., pressing a button). User verification ensures that the correct user is present, typically through a biometric check or PIN.

This distinction allows flexible deployment scenarios depending on the required assurance level.

Authenticators can connect to clients using different transport mechanisms: USB, NFC, Bluetooth, or internal APIs (for platform authenticators). The transport type affects usability and compatibility but does not change the underlying FIDO security model.

When an end-user registers a FIDO key or passkey, IAM persists the transport type used for the registration. The next time the end-user logs in, IAM automatically presents the persisted transport type to the end-user. This prevents end-users from having to choose between all transport types, even unsupported ones, during authentication.

It is possible to disable this default setting. For more information, see Disabling the persisting of FIDO transports

FIDO supports different key storage modes. Resident (or discoverable) keys are stored on the authenticator itself, allowing account selection directly on the device. Resident keys are discoverable because the FIDO client, such as the browser, can ask the authenticator(s) which keys match the login domain being visited. This can improve usability during login and is used in the “autofill” features as described in Use case: FIDO passkeys as first auth factor in IAM. It is also a requirement for usernameless login - see Use case: FIDO passwordless (usernameless) authentication in IAM.

Non-resident keys are managed by the relying party and require the client to provide an identifier during login. Non-resident keys can therefore only be used if the user account has already been identified (the relying party must be able to look up the keys associated with the user account).

Airlock IAM can be configured to require resident keys during registration.

During registration, authenticators may provide an attestation statement, which includes information about the authenticator model, manufacturer, and some other properties. The relying party can take the information into account to enforce registration policies (e.g., only accept authenticators with certain properties).

There are different types of attestation. See FIDO attestation models for further information.