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

Integration scenarios

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.

Authentication Cloud​

The Nevis Authentication Cloud provides authentication as a service. It extends your infrastructure with passwordless authentication and transaction signing services.

In terms of the SDK, several integration scenarios are possible depending on your specific use case. The SDK supported use cases of registration, authentication, transaction confirmation and deregistration can all be achieved with the mobile application as the trigger of the operation, or with one of these operations initiated from another backend system.

In-app scenarios and the Authentication Cloud​

From a conceptual point of view, the Authentication Cloud only supports out of band scenarios. However, the SDK provides convenience APIs for registration, which behave as if the operation was executed in-band by encapsulating the calls required for registration against the Authentication Cloud HTTP API.

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 scenario involves the user first authenticating using an existing means of authentication.

  1. The first HTTP API call to the cloud backend is done against the api/v1/users/enroll endpoint. This endpoint is usually called by another backend application, for example a custom backend to start a user enrollment. The user enrolment is necessary to create the user in the backend before an actual mobile authentication registration can be performed.
  2. Your backend passed the enroll response back to your mobile application. The SDK will use this to perform the actual registration. It makes sense to temporarily store the enrollment.statusToken for verifying the enrolment status at the very end.
  3. You use the SDKs Auth Cloud API registration operation to start the actual registration process. The process will involve asking the user to provide biometric, PIN or device passcode authentication information.
  4. The SDK notifies that the registration completed successfully, another way of verification is to invoke the api/v1/introspect endpoint using the enrollment.statusToken received in step 3.
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 in-app registration, see the Developer Guides Operations chapter.

  • Authentication Cloud API

    For more information regarding the Authentication Cloud API, visit Register Your Mobile App.

In-app authentication​

After registration, the user is able to authenticate in-app using FIDO UAF-based authentication. First, the mobile application initiates the authentication flow by contacting the backend. This is usually done through a custom backend, such as a custom application or API gateway.

  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. After a successful authentication, the SDK will return a JWT. To validate the token, call the api/v1/introspect endpoint.
tip

Out-of-band registration​

  1. The first HTTP API call to the cloud backend is done against the api/v1/users/enroll endpoint. This endpoint is usually called by another backend application, for example a custom backend to start a user enrollment. The user enrolment is necessary to create the user in the backend before an actual mobile authentication registration can be performed.
  2. The Nevis Authentication cloud returns the enroll response to your backend. The enrollment.appLinkUri contains the link required for the registration process. The enrollment.statusToken can be used to check the enrollment progress.
  3. The appLinkUri link can be displayed to the user as clickable link in cases the user operates on a mobile device or rendered in a QR code to allow the user to scan the code using the mobile application or the mobile phones' camera app.
  4. The statusToken obtained in step 2 is used to poll the Nevis Authentication cloud backend using the /api/v1/status endpoint. By polling the status, your custom backend and web application will be able to determine when the registration was completed successfully and proceed afterwards with your scenario, like showing the user a success message or redirecting him/her.
  5. During an ongoing registration, the status API will return pending, indicating that the registration has not been completed yet and has not failed so far.
  6. 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. The SDK requires the appLinkUri for this which the app needs to pass either after the link has been clicked or the QR code scanned.
  7. After the user completed the out-of-band registration in the mobile application, the /api/v1/status endpoint will return succeeded allowing your custom backend and the web application to detect the successful enrollment.
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.

  • Authentication Cloud API

    For more information regarding the Authentication Cloud API, visit Register your mobile app.

Out-of-band authentication​

  1. The first HTTP API call to the cloud backend is done against the api/v1/users/approval 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. The Nevis Authentication cloud returns the approval response to your backend. The appLinkUri contains the link required for the authentication process. THe qrCode contains a base64 encoded image which can be rendered. The statusToken can be used to check the enrollment progress.
  3. The appLinkUri link can be displayed to the user as clickable link in cases the user operates on a mobile device, otherwise the qrCode can be rendered to allow the user to scan the code using the mobile application or the mobile phones' camera app.
  4. The statusToken obtained in step 2 is used to poll the Nevis Authentication cloud backend using the /api/v1/status endpoint. By polling the status, your custom backend and web application will be able to determine when the authentication was completed successfully and proceed afterwards with your scenario, like showing the user a success message or redirecting him/her. The response also contains the token which can be used with the introspect endpoint.
  5. During an ongoing authentication, the status API will return pending, indicating that the authentication has not been completed yet and has not failed so far.
  6. 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. The SDK requires the outOfBandPayload for this which the app needs to pass either after the link has been clicked or the QR code scanned.
  7. After the user completed the out-of-band authentication in the mobile application, call the api/v1/introspect endpoint using the statusToken received in step 2. The introspect endpoint will reply with active indicating the successful authentication.
Status vs introspect endpoint
  • The status endpoint provides information of an ongoing operation. In addition, it returns the token which can be used to query the introspect endpoint.
  • The introspect endpoint is used to check whether a token is valid, and whether the token was actually issued by your Authentication Cloud instance.

The custom backend should call either the status or introspect endpoint depending on the scenario progress.

tip

  • Concept

    For more information regarding the out-of-band authentication concept, see the SDK Concept Guide chapter. Be aware that link, QR code or push messages are available for out-of-band authentication.

  • Mobile SDK Developers

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

  • Authentication Cloud API

    For more information regarding the Authentication Cloud API, visit Mobile App.

  • Authentication Cloud Concept

    For more information about available authentication methods, visit the Authentication methods comparison chapter.

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 updated.
  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 updated.
  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
Last updated on