The figure below gives a high-level overview of the nextAuth architecture. Note that it does not show supporting components and detailed communication flows.
The nextAuth Server (NS) is responsible for handling all communication with the mobile app while performing authentication, transaction signing, push messages… The NS also acts as session/token validation server towards all integrated applications. The NS exposes a REST API, which can either be directly integrated in the business application, or indirectly, through an Identity Provider (IdP) or Resource Gateway.
The nextAuth Mobile SDK runs as part of the mobile app and provides all necessary functionality to perform authentication towards the NS. 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.
The NS 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. nginx 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.
The NS requires a MySQL/MariaDB instance. For production environments, we recommend running a clustered database server to ensure high availability.
A Redis instance is required for synchronisation between NS instances and for in-memory storage.
The NS requires access to Google FCM and APNS in order to send out push messages to mobile devices.