Skip to main content
Version: 3.8.x.x RR

Identity Suite

The Nevis Identity Suite provides software-delivered components for on-premise installations.

In-app registration​

The in-app registration scenario describes how a user registers the mobile application to use FIDO UAF-based authentication. As registration requires an authenticated user, the user first authenticates using an existing means of authentication.

  1. As registration requires prior authentication, your mobile application uses the existing means to authenticate the user. This can be a normal username and password login.
  2. As a result of the authentication, the mobile application receives an authorization token. Depending on the implementation, this can be a cookie or a JWT token.
  3. You use the SDKs registration operation to start the actual registration process. You must provide the authorization token mentioned in step 2 to the registration operation of the SDK. The process will involve asking the user to provide biometric, PIN or device passcode authentication information.
tip

  • Concept

    For more information regarding the registration concept, see the SDK Concept Guide chapter.

  • Mobile SDK Developers

    For hands-on information on how to use the SDK to achieve out-of-band registration, see the Developer Guides Operations chapter.

  • Backend Mobile Authentication Concept and Integration Guide

    A complete description of the in-band registration flow involving all Nevis components and the respective HTTP APIs can be found in the Backend Concept Guide.

  • nevisAdmin 4

    For nevisAdmin 4 related information, visit Configuring Mobile Authentication Use Cases.

In-app authentication​

After registration, the user is able to authenticate in-app using FIDO UAF-based authentication.

  1. You use the SDKs authentication operation to start the authentication process. The process will involve asking the user to provide biometric, PIN or device passcode authentication information.
  2. At the end of the authentication operation, the SDK returns an authorizationProvider containing the authorization element.
  3. The authorization element, a cookie or a JWT token returned in step 2 can be used to access protected resources on the custom backend application.
tip

  • Concept

    For more information regarding the authentication concept, see the SDK Concept Guide chapter.

  • Mobile SDK Developers

    For hands-on information on how to use the SDK to achieve in-app authentication, see the Developer Guides Operations chapter.

  • Backend Mobile Authentication Concept and Integration Guide

    A complete description of the in-app authentication flow involving all Nevis components and the respective HTTP APIs can be found in the Backend Concept Guide.

  • nevisAdmin 4

    For nevisAdmin 4 related information, visit Configuring Mobile Authentication Use Cases.

Out-of-band registration​

  1. As registration requires prior authentication, your custom backend uses the existing means to authenticate the user. This can be a normal username and password login.
  2. As a result of the authentication, the custom backend receives an authorization token. Depending on the implementation, this can be a cookie or a JWT token.
  3. The end user starts the device registration process provided by the custom backend.
  4. Your custom backend starts the our-of-band registration process by creating and dispatching a registration token using the Dispatch Token Service.
  5. How the token is dispatched depends on the Dispatcher used. In this example we're using the QR Code dispatcher.
  6. Your custom backend presents the QR code to the user.
  7. At this time, the browser application starts polling the Nevis backend to receive registration status progress updates.
  8. The Status Service provides information about the current ongoing operation.
  9. As the registration has just been started but the registration token not yet redeemed, the status service will respond with pending.
  10. You should inform the user about the ongoing operation, for example by presenting a loading icon.
  11. You use the SDKs out-of-band registration operation to start the actual registration process. The process will involve asking the user to provide biometric, PIN or device passcode authentication information.
  12. During the ongoing registration on the mobile side, the status service will respond with client registering
  13. After the registration has been completed, the status service will respond with succeeded allowing your custom backend to proceed.
tip

  • Concept

    For more information regarding the out-of-band registration concept, see the SDK Concept Guide chapter.

  • Mobile SDK Developers

    For hands-on information on how to use the SDK to achieve out-of-band registration, see the Developer Guides Operations chapter.

  • Backend Mobile Authentication Concept and Integration Guide

    A complete description of the out-of-band registration flow involving all Nevis components and the respective HTTP APIs can be found in the Backend Concept Guide.

  • nevisAdmin 4

    For nevisAdmin 4 related information, visit Configuring Mobile Authentication Use Cases.

Out-of-band authentication​

  1. The first HTTP API call to the Nevis Identity Suite is done against the token/dispatch/authentication endpoint. This endpoint is usually called by another backend application, for example a custom backend to start a user authentication. The channel defines how the message should be transmitted.
  2. How the token is dispatched depends on the Dispatcher used. In this example we're using the QR Code dispatcher.
  3. Your custom backend presents the QR code to the user.
  4. At this time, the browser application starts polling the Nevis backend to receive authentication status progress updates.
  5. The Status Service provides information about the current ongoing operation.
  6. As the authentication has just been started but the authentication token not yet redeemed, the status service will respond with pending
  7. You should inform the user about the ongoing operation, for example by presenting a loading icon.
  8. You use the SDKs out-of-band authentication operation to start the actual authentication process. The process will involve asking the user to provide biometric, PIN or device passcode authentication information.
  9. During the ongoing authentication on the mobile side, the status service will respond with client registering
  10. After the authentication has been completed, the status service will respond with succeeded allowing your custom backend to proceed.
tip
Transaction confirmation

The FIDO transaction confirmation is technically the same as a FIDO authentication, but additional information is present in the authentication information request, which gives the user details of the transaction.

For this reason, this chapter does not separately list the transaction confirmation flows. See the Concept Operations chapter for additional details.

Last updated on