Architecture

High-Level Overview

The figure below gives a high-level overview of the nextAuth solution. Note that it does not show supporting components and detailed communication flows.

Authentication Server

The Authentication Server (AS) is responsible for handling all communication with the mobile app while performing authentication, transaction signing, push messages... The AS also acts as session/token validation server towards all integrated applications. The AS exposes a REST API, which can either be directly integrated in the business application, or indirectly, through an Identity Provider (IdP) or Resource Gateway.

Mobile SDK

The nextAuth Mobile SDK runs as part of the mobile app and provides all necessary functionality to perform authentication towards the AS. The Mobile SDK consists of a hardened compiled library which contains all security sensitive functions. The compiled library is wrapped in an integration layer which provides the functions to interact with the hardened part. The integration layer is available for both Android and iOS.

Protected Application and/or IdP

The AS on its own only provides a REST API. Custom developed applications can directly interact with this application. There are however plenty of ways to integrate nextAuth into existing software:

• through a reverse proxy (e.g. Traefik with nextAuth configuration), which injects the necessary headers for the application;
• through SAML or OIDC, using the nextAuth IdP;
• through a third-party IdP, either with a nextAuth plugin or a delegation to the nextAuth IdP.

Authentication Server

The Authentication Server consist of three services: the nextAuth Server (NS), the Second Factor Server (SFS) and the Message Center (MC).

• The nextAuth Server handles the authentication flows (i.e. login, signing of transactions and/or documents) and exposes the REST API for the business applications to interact with.
• The Second Factor Server verifies the user’s second factor (PIN or biometric).
• The Message Center handles push and pull messages to the app.

All communication over the WebSockets between the nextAuth Mobile SDK and each of the three services inside the AS is end-to-end secured (mutually authenticated, encrypted).

Services

nextAuth Server

The nextAuth Server verifies the actual authentication: logins and transaction signing. It relies upon nextAuth-enabled app’s Second Factor Server for verifying the second factor and makes use of the nextAuth-enabled app’s Message Center to send messages directly to the intended nextAuth-enabled app.

• The NS only interacts with the SFS through the nextAuth Mobile SDK inside the nextAuth-enabled app: for each second factor verification, the NS will receive an attestation from the SFS that the user's second factor was successfully verified.
• The NS encrypts (using authenticated encryption) messages intended for the nextAuth-enabled app before forwarding these to the correct MC. Before being able to receive messages, the nextAuth-enabled app needs to register with its MC and obtain an app-specific token, that it forwards to the NS. With this token, the NS can send encrypted messages to the MC.

The nextAuth Server also exposes a privileged RESTful interface, such that business applications can integrate with it.

Second Factor Server

The Second Factor Server verifies the user’s second factor (PIN or biometric). Upon successful verification, the Second Factor Server attests to the second factor being verified at that time. This attestation can then be used by the nextAuth-enabled app to prove to a nextAuth Server that is its second factor was successfully verified.

Message Center

The Message Center takes care of push messages, either through Firebase Cloud Messaging (FCM) for Android apps, or through the Apple Push Notification service (APNs) for iOS apps. As a fallback, the nextAuth-enabled app also pulls messages from the Message Center when showing the main screen.

Supporting Components

Database Server

All three services require a Postgres/MySQL/MariaDB instance. For production environments, we recommend running a clustered database server to ensure high availability.

Redis

A Redis instance is required for synchronisation between NS instances and for in-memory storage.

Push Messaging: Google FCM & APNS

The MC requires access to Google FCM and APNS in order to send out push messages to mobile devices.

Mobile SDK

A nextAuth Mobile SDK (inside the nextAuth-enabled app) can handle accounts at different nextAuth Servers, but is associated with only one SFS and one MC. Which SFS and MC is determined by the publisher of the nextAuth-enabled app. It is up to the nextAuth Server whether or not to accept third party nextAuth-enabled apps, i.e. to put trust in their SFS and MC.