Skip to main content
Version: 1.15.x.x LTS

High-Level Architecture

To provide mobile authentication, Nevis Mobile Authentication relies on several Nevis components which contribute to the overall mobile authentication solution. The central components use are depicted in figure Nevis Mobile Authentication architecture.

Nevis Mobile Authentication architecture

Within the Nevis architecture, nevisFIDO acts as a service to implement the FIDO UAF 1.1 specification standard.

The nevisFIDO component tightly integrates with other Nevis components to deliver the complete mobile authentication feature. In the sections that follow, we highlight briefly the functions of the subsystems that work together to ultimately deliver mobile authentication to the client device in the hands of a user.

Client Device​

The client device represents the physical device owned by a user, e.g. a mobile phone. To use and benefit from Nevis Mobile Authentication, the client device requires a Relying Party mobile client to interact and authenticate against a Relying Party backend. The Relying Party mobile client consists of a Client (Business) Application and the FIDO Client.

Relying Party Backend​

The relying party backend characterizes the group of components which in combination act together as the Relying Party backend of a FIDO Relying Party client. In the context of FIDO, communication between a FIDO Client and a FIDO Server always occur via the Relying Party client and Relying Party backend. In Nevis Mobile Authentication, it not only includes the necessary Nevis components described below but also the protected backend entity named Web application in the Nevis Mobile Authentication architecture figure.

Perimeter Infrastructure​

nevisProxy​

Towards the client-facing edge of the system, the nevisProxy component serves as the perimeter server. It's able to protect web applications from unauthenticated access and ensures that authentication takes place before requests are passed to those web applications. In Nevis Mobile Authentication, nevisProxy is configured to accept requests according to the FIDO UAF 1.1 protocol and forwards them to the authentication subsystem. As in all Nevis setups, additional functions of nevisProxy are web application firewall, session management (single sign-on), and reverse proxy functionality like routing and rerouting of requests to downstream components. In Nevis Mobile Authentication, nevisProxy will route HTTP requests to the communication endpoints of nevisFIDO and nevisAuth, which in combination form the authentication subsystem.

Authentication​

nevisFIDO​

At the core of the system, the nevisFIDO component is a specification-compliant implementation of a FIDO Server. As such, it handles UAF protocol level processing and provides support for the FIDO operations (registration, authentication, transaction confirmation and deregistration), as well as some supplementary (non-standard) services. It is the nevisFIDO component that ultimately performs cryptographic operations like signature verification and thus establishes the authenticity of a user. For persistent storage, nevisFIDO relies on the IAM component nevisIDM. The Relying Party mobile client may communicate directly with nevisFIDO (such as for example the process of in-band registration), but in such cases, the client is expected to possess an existing Nevis authentication.

nevisAuth​

Participating in the Nevis Mobile Authentication solution, nevisAuth acts as bridge between the FIDO Client and the FIDO Server, making up for the Nevis authentication specific details nevisFIDO cannot account for. As usual, nevisAuth is used to implement sophisticated authentication flows, including flows that rely on IAM provided by nevisIDM. It does not deal with FIDO UAF protocol level messages but dispatches them to nevisFIDO, delegating the authentication to that component.

Identity Management​

nevisIDM​

In the context of Nevis Mobile Authentication, nevisIDM is acting as a persistent storage of FIDO UAF authenticator credentials. With every user-performed registration on a client device that takes part in Nevis Mobile Authentication, cryptographic information such as an authenticators public key are stored in nevisIDM.

Third Party Backend​

The third party backend characterizes components that are not part of either the Relying Party Backend or the Client Device. Usually these components are located outside the managed infrastructure.

Push Service Provider​

Nevis Mobile Authentication uses push service providers to send push messages to Relying Party Mobile Clients. Push messages are used in out-of-band scenarios to allow communication with a Relying Party Mobile Client without the need to open a channel beforehand.