Authentication

Once the mobile application has an active FIDO registration with the Nevis Mobile Authentication backend, it can make use of FIDO authentication and FIDO transaction confirmation operations.

In a similar way to the registration use cases, we differentiate between the out-of-band (OOB) and in-band authentication types.

The authentication use case is applicable whenever a user wants to perform a login against a backend application.

info

The SDK itself does not differentiate between the different out-of-band mechanisms. It is the responsibility of the apps 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 carried out a Registration first.
• For out-of-band authentication, the user must have a valid Registration to a service, that is capable of performing out-of-band authentication operations. The out-of-band authentication itself can be initiated either on the same device using links, or on a different device using push notifications or QR codes.

Out-of-band authentication

As mentioned in the prerequisites, out-of-band authentication can be achieved in different ways depending on the following:

• The user wants to perform authentication using a singular mobile device, or multiple devices. For example, scanning a QR code is not possible when using a single device.
• The user wants to allow push notifications to be sent to his mobile device, and the device is able to receive the push notification at the time of authentication.

Using push notifications

Using push notifications for mobile authentication is possible on a single device or on multiple devices. However, for same-device authentication, the mobile-only solution provides a better user experience. Additionally, it is able to serve as a fallback in case the push notification was not received by the mobile device.

Prerequisites

The user must register for push notifications before being able to carry out an out-of-band authentication using push.

Out-of-band authentication is initiated by the backend. A possible scenario is where a user wants to access a protected endpoint from outside of the app, for example to log into a web application using a desktop browser. The user must be authenticated first, before the protected endpoint can be accessed. For this to happen, the mobile application integrates the SDK, which provides out-of-band authentication by push notification.

1. The user starts a login.
2. The Nevis Mobile Authentication Backend initiates an authentication, and sends a push message payload to a push provider.
3. An encrypted push notification is sent to the mobile device, which must be handled by the mobile application.
4. The mobile application triggers the out-of-band authentication process with the SDK, by providing the encrypted push notification.
5. Once the mobile application completes the out-of-band authentication process, the user is granted access to the protected endpoint, such as a web application in a desktop browser.

Using links (mobile-only solution)

By using links for authentication, the user is able to simply click a link in a browser-based application to initiate the authentication process. This scenario is of course only valid, if the user wants to perform an authentication on the same device, where the app integrating the SDK is present.

1. Out-of-band authentication is initiated by the backend. A possible scenario is where a user wants to access a protected endpoint from outside the app, for example, to log in to a web application using a browser on the same device. The user must be authenticated first before the protected endpoint can be accessed. For this to happen, the mobile application integrates the SDK, which provides out-of-band authentication through links.
2. When the user clicks the link provided in the web application, encrypted payload information contained in the link is forwarded to the mobile application.
3. The mobile application triggers the out-of-band authentication process with the SDK, by providing the encrypted payload.
4. Once the mobile application completes the out-of-band authentication process, the user is granted access to the protected endpoint, for example, a web application in a desktop browser. For further information, see the Access App Guide.

BPMN

The SDK processes out-of-band authentication by redeeming the token retrieved in the encrypted push notification with the Nevis Mobile Authentication backend. This triggers the FIDO UAF 1.1 protocol, where the backend replies with an authentication request containing a challenge. If the SDK is able to complete the FIDO authentication subprocess successfully, it passes the signed challenge to the backend. The user is fully authenticated in the Nevis Mobile Authentication backend once the SDK successfully completes its post-processing. At this stage, the SDK returns a cookie to the calling mobile application. This cookie can be reused for subsequent calls to endpoints protected by the Nevis Mobile Authentication backend.

info

The corresponding backend use case can be found in the Out-of-band authentication chapter of the nevisFIDO documentation.

In-band authentication

Compared to out-of-band authentication, in-band authentication involves only the mobile application, the SDK and the Nevis Mobile Authentication backend.

1. The mobile application accesses a protected endpoint, but is not authenticated.
2. The Nevis Mobile Authentication backend replies with an authentication request containing a challenge.
3. The SDK uses the challenge from the mobile application to complete the in-band authentication process.

The mobile application passes the challenge to the SDK, which passes the signed challenge to the backend, if it is able to complete the FIDO authentication subprocess successfully. This is detailed in the following figure "BPMN FIDO authentication subprocess". The user is fully authenticated in the Nevis Mobile Authentication backend once the SDK successfully completes its post-processing. At this stage, the SDK returns a cookie or another proof of authentication, such as a JWT token to the calling mobile application. This cookie or token can be reused for subsequent calls to endpoints that are protected by the Nevis Mobile Authentication backend.

tip

The corresponding backend use case can be found in the In-band authentication chapter in the nevisFIDO documentation.

FIDO authentication

Regardless of whether we are in an out-of-band or in-band authentication use case, FIDO authentication always takes place. The important step in FIDO authentication is user verification. If, and only if the user verification process succeeds, can the SDK go on and sign the challenge to complete FIDO authentication. The challenge is signed using the hardware-protected private key that is generated during FIDO registration.