The out-of-band authentication requires the creation of FIDO UAF credentials both on the user's device and on the FIDO UAF server. This operation is called Registration. Without registration, a user will not be able to authenticate. The security requirements of the application protected by Nevis define the nature of the authentication. This could be fingerprint, PIN/password, face recognition, or a combination of several authentication mechanisms.
The out-of-band registration differs from the in-band registration by the additional communication channel, which the out-of-band registration uses to obtain the FIDO UAF Registration Request. A common out-of-band scenario is where a user accesses a resource via laptop or desktop computer, but would like to authenticate with his mobile device (which must be FIDO UAF-enabled). Typically, the application on the mobile device fetches the Registration Request based on a QR code.
- The application generating the credentials has FIDO capabilities. It contains an embedded FIDO Client with access to one or several FIDO Authenticators.
- The user already has existing credentials (a password, for instance) that can be used to authenticate.
- Nevis is configured in such way that only authenticated clients can register FIDO UAF credentials.
- Based on the provided information, the Relying Party Backend Application is able to render the QR code required for registration.
Rendering the registration QR code is not part of the Nevis Mobile Authentication Solution as the registration is typically done directly in the Relying Party Application itself. The documentation provides hints and code snippets to guide the integration.
Example Using QR Code
In the following example, a QR code is used to embed a mobile device into the registration flow. It thereby provides an additional channel ('out-of-band') outside the connection between laptop and Nevis Mobile Authentication. It is assumed that the user has two devices: A laptop to access an e-banking application, and a mobile device with FIDO capabilities to generate the FIDO UAF credentials. The e-banking application is protected in the same realm/domain as the fido Create Registration Token Service.
The numbers in the description below correspond with the numbers in the next figure.
- The user tries to access the e-banking application from a laptop's web browser.
- Nevis detects that an unauthenticated user is trying to access the e-banking application. Nevis asks the user to authenticate. This authentication must follow the security policy required to register new FIDO credentials (a password).
- The user authenticates by providing a password. The user is allowed to access the e-banking application through his browser.
- The user asks the e-banking application to perform a registration.
- The QR code is presented to the user in the browser screen. The user is instructed to scan the QR code using a mobile device.
- The user scans the QR code using a FIDO enabled application in the mobile device.
- The application in the mobile device decodes the QR code and sends the token to the specified redeem token URL. The redeem token URL is assumed to be unprotected.
- Nevis responds to the mobile device. This response includes the authentication methods (fingerprint) allowed by the e-banking application protected by Nevis Mobile Authentication.
- The user authenticates using an authenticator that complies with the requirements of the e-banking server application. New FIDO credentials are created on the mobile device.
- The credentials are sent to Nevis.
- The mobile application stores the credentials and notifies the user about the successful registration.
Dispatch Target Registration
Also part of a complete, successful out-of-band registration is the registration of the mobile device for authentication using push notifications. This procedure is called dispatch target creation. It is out-of-scope of the FIDO UAF Registration and covered by the Nevis Mobile SDK.
This is how it works in a nutshell: Immediately after successful completion of the example flow described above, the mobile device creates a dispatch target ID in Nevis Mobile Authentication. The backend application can later use this dispatch target ID to send out-of-band authentication requests via push notifications to the mobile device. Refer to Dispatch Target Management for details.
The technical flow in the next figure explains the component interaction in detail. The step numbers in the figure do not correlate with the simplified example above.
The complete out-of-band registration flow described here also contains a final conversation that is foreign to the FIDO UAF Registration: the dispatch target registration flow. This secondary flow enables the use of push notifications for FIDO UAF authentication – without registering a dispatch target, no push messages can be sent later. Refer to Dispatch Target Management for an in-depth description.
The numbers in the list correlate with the step numbers in the previous figure.
The user opens the relying party application in a browser.
The browser is pointed at the protected relying party resource. proxy detects that the user is not authenticated. A legacy login flow is initiated by auth.
The legacy login flow is not documented as it heavily depends on the customer's requirements.
The user initiates the FIDO UAF registration process from inside the app in the browser (for example, by pressing a button Register for FIDO UAF).
The app requests registration by accessing the Registration Dispatch Token endpoint of NEVIS Mobile Authentication at proxy. The link dispatcher is used to obtain a link which can be rendered inside a QR code.
proxy transparently forwards the request to the fido HTTP API. fido answers with a token (for a Registration Request, to be retrieved out-of-band).
Example code snippets to integrate the QR code functionality are presented in Out-of-Band Registration Client Code Examples.
The user opens the NEVIS FIDO UAF-enabled mobile application on a mobile device. This mobile device must be furnished with a camera. The user selects the option Register using QR code reader in the mobile app. This triggers the device to read the QR code.
The mobile app reads the QR code from the desktop computer screen.
The mobile app decodes the scanned QR code, which yields a token. The token is an opaque piece of data, which can only be redeemed once, to initiate a proper FIDO UAF Registration Operation.
The mobile app redeems the token at the Redeem Token endpoint.
proxy forwards the redeem token request to fido. In turn, fido sends a Registration Request to the FIDO UAF client on the mobile device.
The FIDO UAF client fetches the trusted facets.
proxy forwards the trusted facets request to fido, upon which fido returns the trusted facets back to the FIDO UAF client.
Now the FIDO UAF client/mobile app begins a user interaction procedure to authenticate the user. The necessary information is first transferred to the mobile device's FIDO UAF Authenticator.
The actual user interaction takes place: The user must authenticate using any of the acceptable methods (fingerprint, username/password, etc.).
After successful authentication, the FIDO UAF Authenticator generates the necessary key material for the authenticated user.
The authenticator creates a FIDO UAF Assertion containing the crypto information, especially the new public key, for the new registration.
The authenticator returns the assertion to the FIDO UAF client/mobile app.
The FIDO UAF client/mobile app packages the assertion in a Registration Response, in accordance with the FIDO UAF protocol.
The mobile app sends the
RegistrationResponse, wrapped up in a
SendUAFResponse, to the Registration Response endpoint.
proxy forwards the
fido performs necessary validation on the incoming Registration Response. When validation is successful, a Credential Record for this registration is stored in idm.
fido marks the FIDO UAF session for this conversation as succeeded.
fido returns the Server Response to the mobile app.
proxy forwards the status query to fido by querying the Status endpoint of fido.
As long as fido has not yet received and validated a Registration Response from the mobile app, the out-of-band registration is still in progress. In this case, fido will return an "in progress" status (as always via proxy).
The out-of-band registration is successfully completed when fido has received a Registration Response from the mobile app, validated and processed it. In this case, fido will return a "succeeded" status (as always via proxy), and mark the FIDO UAF session as "done". The mobile app then displays a success message like "Registration successful" to the user.
After successfully completing the registration, the secondary process of dispatch target registration immediately follows. A prerequisite for this process is another authentication, using the just-registered authenticator. The mobile app sends a request for dispatch target creation to the Dispatch Target Creation endpoint.info
As an alternative, it's possible to provide dispatch targets for creation in the RegistrationResponse sent in step(20). This simplifies the registration as:
- no additional backend call are required to register the dispatch target
- the client doesn't need to perform an additional authentication to be able to access the create dispatch target endpoint (this has direct impact on the user experience on the client side as the user is not asked to present his/her credentials twice during registration
fido stores the dispatch target information in idm, and indicates success/failure back to the client.
You will find example configuration snippets for all involved components in Nevis Component Configuration Examples.