Skip to content

Architecture⚓︎

High-Level Overview⚓︎

The figure below provides a high-level overview of the nextAuth solution. To maintain simplicity, supporting components and detailed communication flows are not pictured here.

High-Level Overview of the nextAuth solution

Authentication Server

The Authentication Server (AS) is responsible for handling all communication with the mobile app while performing authentication, transaction signing, sending push messages, and so on. The AS also acts as the session/token validation server with respect to all integrated applications. The AS exposes a REST API to allow integration with business applications. This API can either be directly integrated in the business application, or it can be used indirectly by means of an Identity Provider (IdP) or Resource Gateway.

Mobile SDK

The nextAuth Mobile SDK is deployed as part of the mobile app and provides all necessary functionality to perform authentication with respect to the AS. The Mobile SDK includes the security-critical functionality a compiled security-hardened library.

As a mobile app developer, you interact with the Mobile SDK, which is available either for Android or iOS.

Protected Application and/or IdP

Newly developed business applications can communicate directly with the Authentication Server (AS) using the REST API. For existing applications, it is also possible to enable nextAuth integration in the following ways: * using a reverse proxy (e.g. Traefik with nextAuth configuration), which injects the necessary headers for the application; * using an Identity Provider (IdP) configured for use with nextAuth; * using a data service, which receives the data delivered through the secure channel.

Authentication Server⚓︎

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

nextAuth Architecture from the server's point of view with its three services and supporting components.

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

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

Services⚓︎

nextAuth Server⚓︎

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

  • The NS only interacts with the SFS through the nextAuth Mobile SDK embedded within 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 the MC and obtain an app-specific token that it forwards to the NS. This token allows the NS to send encrypted messages to the MC.

The nextAuth Server also exposes a privileged RESTful interface to allow integration with your business applications.

Second Factor Server⚓︎

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

Message Center⚓︎

The Message Center (MC) is responsible for sending 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 can also pull messages from the Message Center when the mobile app is in the foreground.

Supporting Components⚓︎

Database Server⚓︎

The three services mentioned above (the NS, the SFS and the MC) require a MySQL or MariaDB instance. For production environments, we recommend running a clustered database server to ensure high availability.

Redis⚓︎

Operation of the nextAuth solution requires a Redis instance. This is used to provide synchronisation between NS instances and to optimize its performance by using in-memory storage.

Push Messaging: Google FCM & APNS⚓︎

The Message Center (MC) requires access to Google Firebase Cloud Messaging (FCM) for Android apps and Apple Push Notification service (APNs) for iOS apps in order to send push messages to mobile devices.

Data service⚓︎

The nextAuth Server (NS) forwards data received from the Mobile SDK through its secure channel to the Data Service (DS). If you are planning to use nextAuth’s secure channel capabilities, operating a DS is also required.

Mobile SDK⚓︎

The nextAuth Mobile SDK (which is embedded inside the nextAuth-enabled app) can be associated with multiple nextAuth Servers. This allows different user accounts to be located on different nextAuth Servers. However, for the SFS and for the MC, a single app must be associated with a single SFS and a single MC. The publisher of the nextAuth-enabled app decides with which SFS and which MC it wants to be associated. However, it is up to the nextAuth Server to decide whether or not to accept (trust) the app’s SFS and MC.

nextAuth Architecture from the Mobile SDK's Point of View