Out-of-band authentication allows users to authenticate on their mobile phones. Thus, a user can authorize sessions on different devices. For example, the user gains access to the e-banking application on his laptop by authenticating via the fingerprint reader on his mobile phone.
- The user must have two devices at hand. One device is a laptop, where the user must perform a legacy login. The other is a mobile device, where the user authenticates.
- A mobile application is installed on the mobile device. This mobile application must be able to handle the FIDO UAF protocol as well as push notifications.
- The mobile application has to register itself against the backend as the receiver of out-of-band messages. Dispatch Target Management describes this procedure.
- The user has previously registered FIDO Authenticator credentials on his mobile device. Registration can be done via In-Band Registration.
Example with Push Notification
The numbers in the description below correspond with the numbers in the next figure.
- The user opens the e-banking application in the browser on the laptop.
- The e-banking application is protected by Nevis, which renders a login page and asks for a username.
- The user provides his username.
- Now Nevis renders a page in which the user must specify the mobile device to be used for authentication.
- The user selects the mobile device to be used for authentication.
- Nevis sends a push notification to the selected mobile device.
- The user receives a push notification on the mobile device and taps it.
- The mobile application receives the push message and contacts Nevis to proceed with the FIDO authentication.
- Nevis now requests the mobile device to authenticate.
- The user performs an In-Band Authentication using the fingerprint-based FIDO Authenticator in the mobile device.
- The user completes the authentication process on the mobile device.
- Meanwhile, the client on the laptop frequently checks Nevis about the status of the user's authentication. When the user has successfully authenticated on the mobile device, the laptop client takes over again.
- Nevis allows the laptop client to access the e-banking application.
The channel linking mechanism allows the end user to verify the link between devices that participate in out-of-band authentication. Currently, the visual string channel linking is the only channel linking method supported out-of-the box by Nevis Mobile Authentication.
This is how it works: The system generates a random string in the backend and sends the string to both devices used for the out-of-band authentication. Each device shows the string to the end user. The end user must confirm that the same string is presented on both devices.
The following figure illustrates the process:
- The user provides the login credentials
- A random character string is displayed on the desktop screen
- The Nevis Access App receives the authentication push message
- The same character text is displayed in the Nevis Access App, the user can confirm or opt-out
- Upon confirmation, the user is logged in
The visual string channel linking in Nevis Mobile Authentication is configured in the
OutOfBandFidoUafAuthState. For more details, check the nevisFIDO Reference Guide, in particular the Channel Linking section of the OutOfBandFidoUafAuthState chapter.
One way of transferring authentication information to the mobile device is by means of the Firebase Cloud Messaging service (short FCM service). The example in the technical flow section below, for instance, shows how nevisFIDO uses the FCM service to transfer the required authentication information to the user's mobile device via a push notification. An alternative option to transfer authentication information to the mobile device is a QR code. A second alternative is a link that can be used to open the authentication application. This is a suitable option when the web browser runs in the mobile device. Nevis Mobile Authentication provides both alternatives.
You can use these different out-of-band mechanisms on their own or as a fallback for the other mechanism. It may happen, for example, that the FCM service fails because of a temporary network problem between nevisFIDO and the FCM service. In such a case, you can use the QR code approach as a fallback.
For more details, check the Dispatching for Out-of-Band Operations - Push Notification Fallback in this guide and the Authentication Retry/Fallback Example section of the OutOfBandFidoUafAuthState chapter in the nevisFIDO Reference Guide.
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 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 points at the protected relying party resource. nevisProxy detects that the user is not authenticated.
nevisProxy informs the browser that a login is required and redirects to
The browser obtains the login page from nevisAuth.info
Supplying the user's username (
loginid) is the minimum requirement for an out-of-band login with Nevis Mobile Authentication. Refer to the configuration snippets for more detailed information.
The user provides a username (
The browser posts the information from the login form to nevisProxy, which forwards the request to nevisAuth.
IdmUserVerifyStateretrieves the user information based on the provided username in the login form. This user information is required to be able to operate with the internal user identifier in the subsequent nevisAuth AuthStates.
After retrieving the user information from nevisIDM, a transition to the next AuthState is executed.
OutOfBandFidoUafAuthStatequeries the available dispatch targets in nevisFIDO.
nevisFIDO queries nevisIDM for available dispatch targets for the given user based on the user's
A JSON list containing all available dispatch targets is returned to the browser.
The user selects a dispatch target, if more than one is registered.
The browser-side application initiates the dispatching by sending the
dispatchTargetIdof the selected dispatch target to nevisAuth.
OutOfBandFidoUafAuthStatein nevisAuth creates a
GetUafRequestfor the given username.
The AuthState calls the nevisFIDO endpoint to dispatch a token request and supplies the
GetUafRequesttogether with the
dispatchTargetIdof the previously selected dispatch target.
If channel linking has been enabled, the AuthState generates a random string and sends this random string in the dispatch token request.
nevisFIDO generates a redeem token and stores the corresponding
GetUafRequest. The mobile application will redeem the token later on.
nevisFIDO obtains the dispatch target information, based on the
dispatchTargetId, from nevisIDM.
nevisFIDO encrypts the data to be sent to the dispatch target with JWE, using the encryption key stored in the dispatch target for the given user.
nevisFIDO sends the encrypted message to the dispatcher configured in the dispatch target (in this example to the Firebase Cloud Messaging Service)
nevisFIDO responds to the dispatching operation with a session identifier (
sessionId). This session identifier allows checking the session status later on.
sessionIdis cached in nevisAuth to indicate an ongoing operation.
nevisAuth forwards the response from nevisFIDO to the client application in the browser.
If channel linking has been enabled, nevisAuth also returns the random string generated previously (step 13).
The client application periodically polls the backend for status updates, by sending the sessionId obtained in step 20.
If channel linking has been enabled, the client application presents the random string generated in the nevisAuth AuthState to the user. This way, the user can verify that the authentication request received in his mobile device corresponds to the one triggered from the desktop.
Because a session is in progress (step 19), the
OutOfBandFidoUafAuthStatequeries the nevisFIDO status interface.
nevisAuth forwards the current authentication status, as responded by nevisFIDO, to the client application. This status can be translated into a progress message readable by the user.
Upon receiving the push message, the OS of the mobile device delegates the handling of the message to the relying party mobile client application (short: mobile client app).
The mobile client app uses its locally stored encryption key to decrypt the JWE encrypted message payload.
If channel linking has been enabled, the mobile client application presents the random string generated in the nevisAuth AuthState to the user. This way, the user can verify that the authentication request received in his mobile device corresponds to the one triggered from the desktop.
If the user does not cancel the authentication, the mobile client app uses the endpoint specified in the push message data payload to redeem the token, which is also included in the push message data payload.
nevisFIDO retrieves the previously stored
GetUafRequest(step 14) and validates it against the existing policy.
ReturnUafRequestis generated containing the
AuthenticationRequestwhich was inquired by the
The loop of step 21 repeats, querying the current authentication status.
See step 22.
By now, the current status has changed to
clientAuthenticating, indicating that the relying party mobile client application has redeemed the token and obtained an
The relying party mobile client application requests the trusted facets from the backend.
The request is forwarded by nevisProxy to nevisFIDO.
The relying party client application triggers the user authentication by presenting the authenticator(s) specified in the
The user is asked to provide the authentication credentials.
The assertion for the response is generated using the now unlocked private key.
The relying party mobile application sends the
AuthenticationResponseto the backend.
nevisProxy forwards the request to nevisFIDO.
nevisFIDO obtains the FIDO UAF credentials from nevisIDM.
nevisFIDO responds to the relying party mobile client application with a ServerResponse message containing information about the authentication operation success or failure.
The relying party client application in the browser polls the current status (see step 21).
See step 22.
Because the relying party mobile client application completed the authentication operation in step 37, the status now returned by nevisFIDO indicates authentication success.
nevisAuth returns the status response from nevisFIDO to nevisProxy.
nevisProxy forwards the status response form nevisAuth to the browser application. In this example we assume the status is "succeeded", which indicates a successful authentication operation in nevisFIDO.
To finalise the login, the login application in the browser must now redirect to the form action.
nevisProxy again forwards the request to nevisAuth as authentication is still ongoing.
nevisAuth executes a transition to the next AuthState (because of the successful authentication operation in nevisFIDO).
DirectResponseAuthStatesets the response payload as JSON.
DirectResponseAuthStateis the last AuthState in the flow. It sets the response to
The response is forwarded to nevisProxy (including the
nevisProxy will issue a final redirect because authentication is done. This occurs because the
InterceptionRedirectproperty of the
IdentityCreationFilteris set to
nevisProxy sends the redirect to the browser.
The browser follows the redirect.
nevisProxy forwards the request to the relying party backend application.
User Agent (Browser) Perspective
The Nevis backend mentioned in the following flow is simplified. Refer to the backend flow in the previous figure for a more detailed view.
The user opens a browser to visit an e-banking application.
The user agent issues a GET request to the relying party backend. Nevis detects that the user is not authenticated.
Nevis returns an HTTP redirect to the browser.
The browser issues a GET request to /?login to perform authentication.
/?loginis the specified form action URL.
Nevis returns the login form. The form contains an input field requiring the user to provide his loginId. The user's login ID can be, for example, his username.
The user provides his
The user agent returns the data in the form to Nevis using the form post mechanism.
/?login (form action)
Nevis returns another form named "ooblogin". This form contains the required information for the out-of-band login as hidden fields.
The client library posts the loginId of the user to the Nevis backend.
/?login (form action)
The Nevis backend returns the dispatch target(s) of the user with the given
If more than one dispatch target is available, Nevis returns a selection list with all available dispatch targets. This allows the user to choose the dispatch target to receive the authentication request, for example his mobile device.
The user selects the dispatch target of his choice.
The selected dispatch target (
dispatchTargetId) is sent back to the NEVIS backend together with the loginId and additional dispatch information. This additional information consists of a title to be shown in the push message on the mobile device.
/?login (form action)
The Nevis backend returns the dispatch result from the previous step. If channel linking is enabled, the channel linking information is also provided with the dispatch result information.
If channel linking has been enabled, the random string generated in the nevisAuth AuthState is presented to the user.
fidoUafSessionIdobtained in step 15 together with the loginId to the Nevis backend to query the current authentication status.
/?login (form action)
The Nevis backend returns the current authentication status for the given
The browser issues a GET request to the specified form action URL (as a result of step 19). The Nevis backend is now able to recognize the current session as authenticated.
/?login (form action)
The Nevis backend issues a redirect to the URL originally requested by the user (in step 2).
The browser follows the redirect to the e-banking application.
You will find example configuration snippets for all involved components in Nevis Component Configuration Examples.