Nevis Mobile Authentication

Nevis Mobile Authentication builds up on top of the FIDO UAF 1.1 protocol and supports the registration, authentication, transaction confirmation and deregistration operations of FIDO UAF 1.1. It enables secure and convenient authentication for relying applications by letting users verify their identity via their mobile device. This is achieved by integrating the relying web applications with the Nevis Security Suite and implementing Nevis Mobile Authentication client-capabilities in a mobile application. This is depicted in figure High-level Architecture of Nevis Mobile Authentication.

The Nevis Mobile Authentication server-side is based on Nevis components including nevisIDM as the Identity Management System. This ensures end-to-end compatibility and decreases integration efforts with third-party components. For more details on the server-side architecture, see the High-Level Architecture.

Mobile Authentication Devices

Nevis Mobile Authentication focuses on mobile devices with FIDO Client capabilities and FIDO Authenticators. To connect the FIDO Clients and the FIDO Authenticators with the server-side of Nevis Mobile Authentication, a small communication layer must be implemented in the Relying Party client application. This abstraction layer is referred to as Nevis Mobile Authentication client. The Nevis Mobile Authentication client is responsible to communicate FIDO UAF protocol messages received by the mobile application to the FIDO Client and from the FIDO Client to the Relying Party.

The FIDO UAF architecture anticipates that devices and operating systems are shipped with FIDO UAF Clients and Authenticators. In such cases, the Nevis Mobile Authentication client may build up on that as depicted in figure External FIDO Client and Authenticators. However, since FIDO UAF 1.1 is a relatively new standard, not all mobile devices and operating systems are shipped with FIDO-capabilities, yet. To support a wide range of mobile client devices and operating systems, Nevis Mobile Authentication also anticipates FIDO Clients and software-based FIDO Authenticators to be embedded into a mobile application as depicted in figure Embedded FIDO Client and Authenticator.

Nevis Mobile Authentication Client SDK

To allow quick and easy development of mobile applications with support of Nevis Mobile Authentication, a Nevis Mobile Authentication Client SDK for Android and iOS is available. For more information, see Nevis Mobile Authentication Client SDK - Technical Documentation Home.

Nevis Mobile Authentication anticipates two integration scenarios for the Nevis Mobile Authentication client on the mobile device:

• A Nevis Mobile Authentication client built into a mobile Business Application which requires authentication (built-in).
• A Nevis Mobile Authentication client built into a dedicated native mobile application solely built to implement authentication, transaction confirmation, registration and deregistration scenarios (Access App).

If Nevis Mobile Authentication client capabilities are built into a Business Application, FIDO protocol messages between the server-side and the client-side may be directly transferred through established communication channels. If Nevis Mobile Authentication Client capabilities are built into a separate dedicated application for authentication, out-of-band push notifications must be used to establish a new communication channel between the server-side and the Access Application.

Based on the client-side integration type, Nevis Mobile Authentication thus supports two authentication concepts.

Mobile Authentication Concepts

In Nevis Mobile Authentication, we distinguish between the basic usage scenarios out-of-band authentication and in-band authentication. In in-band authentication, authentication is done within the same application that requires it. In out-of-band authentication, authentication is done in an application separated from the application that requires it. There is no direct communication between the two applications.

In-Band Authentication

Example

• A mobile banking application which does not require the installation of another application to handle the authentication. All required functionality is built into one application.

In case of in-band authentication, FIDO Protocol messages are transferred through the same established communication channels the Business Application is using. This is called in-band communication. Once an application requests to log in, to access protected resources (1), the server-side responds with an AuthenticationRequest including a challenge (2). The end user locally verifies his identity and cryptographically signs the challenge (3). An AuthenticationResponse is then returned to the server-side (4), which verifies the signature (5) and returns an access token (6).

Out-of-Band Authentication

Example

• A mobile banking application handles the banking-related business logic but requires the presence of another application (Access App) on the same or a different mobile device to handle the authentication.
• A web application for banking is accessed from a browser on a laptop. The web application handles the banking-related business logic but requires authentication by a distinguished Access App which is installed on a mobile device.

In out-of-band authentication, there is no direct communication between the application that requires authentication and the application that conducts the authentication. That is, FIDO Protocol messages must be transferred through another channel than the channel used by the Business Application. This is called out-of-band communication. In Nevis Mobile Authentication, an out-of-band channel is established by delivering a message to the Access Application via push notification.

Out-of-band authentication can take place on the same physical device with two logically separated and isolated applications as depicted in the figure Out-of-band authentication on same device. One application handles the business logic, whilst the other handles authentication.

Once an application is required to log in to access protected resources on the initial in-band communication channel (1), the server-side sends a push notification to the end user's associated Access App, containing a reference to an AuthenticationRequest. This triggers the Access App to request the referred-to AuthenticationRequest through a newly established out-of-band channel (3). The end user locally verifies his identity and cryptographically signs the challenge contained in the AuthenticationRequest (4). An AuthenticationResponse is then returned to the server-side (5), which verifies the signature (6) and returns an access token to the application that initially requested login (7).

Due to the fact that there is no direct communication between the application that requires authentication and the application that conducts the authentication, authentication can also take place on a separate device. The following figure Out-of-band authentication on multiple devices illustrates this use case.