Fast Identity Online (FIDO) Authentication is a set of open technical specifications that define user authentication mechanisms that reduce the reliance on passwords. To date, the FIDO Alliance published three sets of specifications:
- FIDO Universal Second Factor (FIDO U2F) provides a standard means for interfacing a second-factor hardware authenticator. This interface is mainly used by Web browsers to allow Web applications to interface with a user’s hardware authenticator. With the release of FIDO2, U2F has been renamed as CTAP1.
- Client to Authenticator Protocols (CTAP) enables users to authenticate to a Web or native application using an authenticator embedded in the host computer or connected to the host computer. Similar to FIDO U2F, CTAP is designed to provide a standardized interface to a hardware authenticator.
- FIDO Universal Authentication Framework (FIDO UAF) defines a framework for users to register their device (i.e. laptop, desktop, mobile) to the online service and select one of the local authentication mechanisms available on the device to authenticate its user. The online service can select which locally available authentication mechanism it will accept. For example, users can register their mobile device and select its embedded fingerprint sensor as the local authentication means used to authenticate them to the online service. Other common authentication mechanisms include looking at the camera, speaking into the microphone, or entering a PIN. Once registered and accepted by the online service, users can authenticate to the online service using the local authentication action registered instead of using the more traditional username and password options.
FIDO protocols are designed from the ground up to protect user privacy. The protocols do not disclose sensitive user data that can be used by different online services to collaborate and track a user across the services. Other sensitive data like biometric prints and PINs never leaves the user’s device to ensure it cannot be intercepted or compromised by an attacker.
To authenticate a user, an application – often referred to as the relying party – uses FIDO-specified client-side APIs to interact with a user’s registered authenticator. For web applications, client-side APIs include WebAuthn implemented by the web browser, which in turn calls on FIDO CTAP to access the authenticator.
To authenticate a user, the relying party passes a cryptographic challenge to the registered authenticator and evaluates the response to determine the authenticity of the secrets stored on the client device and used to produce the response.
“Under the hood” FIDO utilizes asymmetric cryptography to ensure that all sensitive secrets and cryptographic key material remain on the client device at all times and are not transmitted to the authenticating service.
How does FIDO authentication work?
FIDO authentication requires an initial registration step. In cases where the user device supports multiple forms of authentication (i.e. fingerprint scanner, voiceprint recorder, face ID, etc.), the user is asked to choose a FIDO compliant authenticator from the options available on the device that matches the authenticating app’s acceptance policy. The user then unlocks the FIDO authenticator using whatever mechanism is built into the authenticator – e.g. by providing a fingerprint, pressing a button on a second–factor device, or entering PIN.
Once the authenticator is unlocked, the user’s device creates a new and unique public/private cryptographic key pair that will be used for authenticating access. The public key is then sent to the online service and associated with the user’s account. The private key and all other sensitive data related to the chosen authentication method – for example, biometric prints – remain on the local device and never leave it.
Authentication requires the client device to prove possession of the private key to the authenticating service by successfully responding to a cryptographic challenge. The private key can only be used after successfully authenticating using the registered authenticator, for example by swiping a finger on the fingerprint sensor, entering a PIN, speaking into a microphone, inserting a second–factor device, pressing a button, etc. The device then uses the user account identifier provided by the service to select the correct key and cryptographically sign the service’s challenge. The signed challenge is sent back to the service, which verifies it with the stored public key and logs in the user.