Overview of the FIDO Client and its authenticators
- 27 Oct 2024
- 3 Minutes to read
- DarkLight
Overview of the FIDO Client and its authenticators
- Updated on 27 Oct 2024
- 3 Minutes to read
- DarkLight
Article summary
Did you find this summary helpful?
Thank you for your feedback
With the FIDO Client and its authenticators for Android and iOS you can perform strong authentication with FIDO in your app instead of having to rely on passwords. The FIDO Client allows a user to login to a mobile application of a relying party (such as a banking app) using different types of password-less authentication.
Each time the user logs in to the mobile application using FIDO, based on the type of authenticator, the private key stored on the device will be extracted and verified. Once verified, the device communicates with the FIDO Server via JSON messages standardized by the FIDO Client and its authenticators.
All FIDO keys and secrets always remain on the device itself and cannot be shared or transferred to another device. Also, the FIDO UAF Client SDK does not expose any ID that binds a device to a FIDO user.
Features of the FIDO Client and its authenticators
The FIDO Client and its authenticators offer the following features (for more detailed information, see About the Biometric Authenticator and About the Application PIN Authenticator):
Support for multiple authenticators
Determining available authenticators on a device
Removal of local registrations for a specific or all authenticators
Standard FIDO UAF operations
Process FIDO UAF requests received from server and generate Fido UAF responses
Communicate standard FIDO errors to the integrator
Limitations
The following limitations apply to the FIDO Client and its authenticators:
Exclusively API-based
The FIDO Client and its authenticators do not provide any user interface (UI) or graphic user interface (GUI), except for the UI provided by the operating system (only for biometric authentication on Android). Consequently, there are no customizable system dialogs or menus, and the FIDO Client and its authenticators do not proivde human readable or user-facing messages like general error messages.
No calls or triggering requests to FIDO servers
The FIDO Client does not have a communication layer to make API calls to a FIDO server and does not trigger any requests such as registration, deregistration.etc.
No fallback to other authentication methods
Neither of the authenticators allows a fallback to any other authentication method than that specified with the authenticator itself.
Support for multiple authenticators
You can enable the registration, deregistration, and use of multiple authenticators for your users and their FIDO UAF operations. To provide this functionality, you need to create an instance of the FIDO UAF client from the factory. The instance returned from the factory has all injected authenticators to work with.
To create an instance of the FIDO UAF client
Instantiate all authenticators you wish to use with your FIDO UAF client.
Pass those authenticators as an array to the factory.
Pass a callback/listener to the factory to choose between available authenticators when requested by the FIDO UAF Client SDK.
Pass a callback/listener to the factory to confirm or refuse a FIDO transaction when requested by the FIDO UAF Client SDK.
Regardless of how many authenticators are registered during the time a FIDO request is being processed, the FIDO UAF Client SDK calls the callback/listener and provides the available authenticator combinations that can be used with that request, even if there is only a signle authenticator combination available for that operation.
You can either choose one of the authenticator combinations programmatically, or display a list of available authenticators to your user for them to choose and return an authenticator combination to the FIDO Client instance. Once the chosen combination is received, the SDK will continue processing the FIDO request.
The same behaviour applies when confirming or refusing a FIDO transaction. In that case the callback/listener will be called and the SDK will wait for a response you defined to continue processing.
When obtaining an authenticator from the factory and this authenticator is not available on the device (e.g., fingerprint on an iPhone 15), the factory method will throw an exception. If the authenticator is available, an instance will be returned.
Was this article helpful?