Registration
Before being able to authenticate by using a FIDO authenticator, the user must register their authenticator with the Nevis Mobile Authentication backend. This process is called FIDO registration. We differentiate between two registration types: Out-of-band registration and in-band registration.
The SDK does not differentiate between the different out-of-band mechanisms. It is the application's responsibility to receive the out-of-band messages and supply the SDK with the message payload.
Prerequisites
- The mobile application contains the Nevis Mobile Authentication SDK.
- The user already has existing credentials, for example, a password, that can be used to authenticate.
Out-of-band registration
Out-of-band registration can be achieved in two ways depending on whether the user wants to use a single (mobile) device or multiple devices.
In the case of out-of-band registrations, the registration process is initiated by the backend. Since the backend has no means to communicate directly with the client before it is registered, information must be transferred through an out-of-band channel. The following happens:
The user initiates an out-of-band operation in one of the following ways:
- Through a QR code containing a token to redeem a FIDO registration request from the backend in case multiple different devices are involved (for example a mobile phone and a desktop PC).
- If there is only one device involved, the out-of-band registration is started from the browser of the device by clicking a link (see iOS universal links, Android app links). The link contains the same information as the QR code.
The mobile application forwards the payload information to the Nevis Mobile Authentication SDK.
The SDK initiates FIDO registration by redeeming the token with the Nevis Mobile Authentication backend. The backend replies with a FIDO registration request containing a list of supported authenticators. If the SDK was able to complete the FIDO registration sub-process successfully, it passes the freshly generated public key to the backend. At this stage, the mobile application can be used for FIDO authentication.
For further details regarding the client behaviour see the Access App Guide, and for backend behaviour the Dispatching for Out-of-Band Operations - Push Notification Fallback.
The FIDO registration sub-process requires interactions with the user. See the FIDO Registration section.
The corresponding backend use case can be found in the Out-of-band registration chapter of the nevisFIDO documentation.
In-band registration
In-band registration is a FIDO registration that is initiated directly by the SDK integrated in the mobile application. The only communication channel involved is the one established between the SDK and the Nevis Mobile Authentication backend.
The mobile application initiates an in-band registration process with the SDK. In a similar way to out-of-band registration, the backend replies to the request of the SDK with a FIDO UAF 1.1 registration request containing a list of supported authenticators (see the figure). If the SDK is able to complete the FIDO registration subprocess successfully, it passes the freshly generated public key to the backend. At this stage, the mobile application can be used for FIDO authentication.
In a realistic scenario, the backend is always configured to require authorization to carry out FIDO registration. Specifically for in-band registration, the mobile application must pass an authenticated session, for example in the form of a cookie, to the SDK when initiating registration. To obtain a session of this type, the mobile application must first authenticate with the Nevis Mobile Authentication backend, for example by providing a username and password.
- The FIDO registration subprocess requires interactions with the user. See the FIDO registration section.
- The corresponding backend use case can be found in the In-Band Registration chapter of the nevisFIDO documentation.
FIDO registration
The SDK delegates the responsibility of interacting with the user who needs to go through a verification process to the app. The list of supported authenticators is used during this interaction. The app asks the user to choose the authenticator that will be used for the ongoing FIDO registration. After successful user verification, the SDK generates a private/public key pair which is stored securely on the phone. To finalize the FIDO registration process, the SDK creates a FIDO registration response, and sends it back together with the public key to the Nevis Mobile Authentication backend.
The SDK also sends a device ID in the FIDO registration response to the Nevis Mobile Authentication Backend. This ID is stored as an attribute of the registered authenticator and the dispatch target. With this information, it is easier to identify those authenticators and dispatch targets that belong to the same device, when the UAF credentials are administered later on.
The generation of the device ID differs per platform.
On iOS, the identifierForVendor value is used. This identifierForVendor value is the most unique identifier for an iOS device, which can be retrieved programmatically. It stays constant, and changes only in a few cases mentioned in the official Apple iOS documentation. Android uses a randomly generated UUID value.
Scenarios where the iOS identifier changes are not automatically handled by the Nevis Mobile Authentication Solution and must be implemented as part of the integration.