Dispatching for Out-of-Band Operations - Push Notification Fallback

Description

In the context of out-of-band authentication, a user-friendly approach is to send the information with the Firebase Cloud Messaging service (short FCM service). The user must only click the push message that he/she receives on his mobile phone to open the application and proceed with the authentication.

But sometimes push service notifications do not work. In case of an outage in the provider network, for example, or when there are problems with the coverage. For these situations, Nevis Mobile Authentication provides two fallback authentication mechanisms. This chapter explains how the end user application interacts with the backend to trigger the fallback authentication mechanisms.

Fallback Mechanisms

Nevis Mobile Authentication provides two different out-of-the-box fallback authentication mechanisms:

• QR codes
  The QR Code fallback mechanism is useful if the user accesses the protected web application via a desktop PC or laptop. Instead of sending a push notification to the user's mobile device, Nevis Mobile Authentication displays a QR code on the PC or laptop. The user must then scan this QR code with his mobile device to trigger the authentication.
• Deep links
  QR codes will not work if the user accesses the protected web application on the same mobile device used for mobile authentication - you cannot scan a QR code with the device displaying the code. In this case, it is possible to use deep links. When the user clicks on such a link, the authentication mobile application opens.

For more information, see the nevisFIDO Reference Guide (sections "QR Code Dispatcher" and "Link Dispatcher").

The interaction with the backend is the same in both cases. The section below explains how this interaction works.

Fallback in Out-of-Band Authentication

To be able to understand how the fallback authentication works, you first need to understand the out-of-band authentication on the relying party level.

A relying party is for example a nevisAuth instance in case of an application protected by Nevis, or a credit card transaction web application in case of a payment. The relying party asks nevisFIDO whether a user has been authenticated. For this, the relying party uses the nevisFIDO session ID. When the user has been authenticated, the relying party gives the user access to the application that required authentication. So nevisFIDO does the authentication, and the relying party performs the authorization.

Now suppose it is necessary to use a fallback authentication mechanism. In this case, the relying party requests a new authentication, based on the respective fallback authentication mechanism (QR code or deep link). For this new authentication request, nevisFIDO will generate a new session ID, here referred to as sessionID2.The relying party will then check whether the user authenticated successfully for the session sessionID2.

info

It is up to the relying party whether to grant the user access to the requested application as soon as authentication is completed for the initial session ID, or only if the user has authenticated for the last session ID, sessionID2. Suppose, for example, that the initial out-of-band mechanism is push notification, and the fallback mechanism is QR code. Should the displaying of the QR code then invalidate the authentication with the push notification (which might only arrive a bit late)? The choice may depend on the desired user experience.

If nevisAuth is the relying party, it only uses the authentication triggered last to check whether nevisFIDO authenticated the user (the authentication that was triggered last is the one with session ID sessionID2). This means that even if the user authenticates successfully with the initial request, nevisAuth will not use this to grant access to the protected application; nevisAuth only considers the user as authenticated when the latest generated authentication (with sessionID2) is completed. This makes the approach of nevisAuth in the fallback case very similar to its approach in the standard case.

The fallback process consists of the following steps:

1. The web browser connects with the relying party asking for a service (access to a protected resource, do a credit card purchase, etc.). The relying party notes that the user must authenticate.
2. The relying party sends a request to nevisFIDO asking to authenticate the user. This is done by invoking a dispatcher, such as the Firebase Cloud Messaging dispatcher.
3. nevisFIDO returns a dispatch response to the relying party. This response contains a nevisFIDO session ID (sessionID1). The relying party uses the returned nevisFIDO session ID to determine whether the user authenticated in nevisFIDO.
4. The relying party forwards the nevisFIDO response to the web browser.
5. The web application running in the web browser decides that a fallback authentication is required. Multiple criteria can lead to this decision: Too much time has passed since the triggering of the initial authentication, the user wants to use an alternative authentication mechanism, etc. The web browser connects with the relying party asking for a new authentication with a fallback authentication method.
6. The relying party sends a request to nevisFIDO asking to authenticate the user with the fallback mechanism. If the fallback mechanism is QR code, nevisFIDO invokes the QR Code dispatcher. If the fallback mechanism is deep link, nevisFIDO invokes the Link dispatcher.
7. nevisFIDO returns the dispatch response to the relying party. This response contains a nevisFIDO session ID (sessionID2). The relying party uses the returned nevisFIDO session ID to determine whether the user authenticated in nevisFIDO.
8. The relying party forwards the nevisFIDO response to the web browser.
9. The web browser receives the nevisFIDO response. If QR code is used, the user scans the rendered QR code with the mobile authentication application. If a deep link is used, the user clicks the link to open the mobile authentication application. In both cases, the information is transmitted from the web browser to the authentication application.
10. The user authenticates using the mobile device.
11. The relying party checks with nevisFIDO whether the user has been authenticated. For this, the relying party uses the relevant session ID. The check can be triggered either by the relying party itself or indirectly by the web browser (by asking the relying party to do the check). If the user has been authenticated, the relying party gives access to the requested service. In case of a transaction confirmation, like a credit card payment, the relying party must guarantee that the payment is done only once. If the relying party allows authentication with the initial nevisFIDO session (sessionID1), either sessionID1 or sessionID2 should result in a single payment (for more information, see the Info box above.

The following figure shows the fallback scenario if a user wants to access an e-banking application via the web browser in a desktop:

The figure below shows the fallback scenario if a user wants to access the e-banking application via his/her mobile device:

In the Nevis Mobile Authentication solution, it is the web application (the client) that decides whether to trigger a fallback authentication. Theoretically, it is also possible to decide this at the relying party level (the backend). However, this should be avoided:

• Using a fallback mechanism has an impact on the user interaction. This means that the client application is necessarily impacted anyway. Leaving most of the fallback logic at the client level keeps things simple at the backend.
• Some relying parties (such as nevisAuth) can only determine limited fallback criteria. Leaving this decision at the client level makes the mechanism more flexible and thus allows for a better user experience.