Skip to content

Concepts⚓︎

Functionality of the Mobile SDK⚓︎

The nextAuth Mobile SDK includes all the necessary functionality to create and manage nextAuth accounts on one or more nextAuth servers, as well as to allow logins from these accounts. A login can originate locally (from the mobile app side), or from a session in another app, or even from another device. Every login attempt results in the creation of a session and will trigger the necessary user interaction by means of callbacks.

The Mobile SDK also handles push messages, keeps a history of all interactions and has a built-in QR code processor.

Core Entities⚓︎

Servers⚓︎

For each server where the Mobile SDK is used to register one or more accounts, the Mobile SDK stores the corresponding server parameters (as defined by the server). Upon creating a session, these server parameters are updated if needed.

The server parameters have a significant influence on how the Mobile SDK will behave for sessions involving accounts on a given server.

Accounts⚓︎

The Mobile SDK keeps a list of registered accounts, whereby each account allows for authenticating towards a specific server as a specific user, and receiving messages from the corresponding server.

Accounts can be deleted both from the Server SDK and from the app. When an account is deleted by a server-side request, the server sends a message to the Mobile SDK instructing it to delete the relevant account. Likewise, if an account is deleted by an app-side request, the Mobile SDK will notify the server that an account was deleted. Note that when an app is uninstalled from a user’s device, all accounts will be effectively deleted, but there will not be a notification of this to the nextAuth Server.

Sessions⚓︎

Each login has a session associated with it. A session can be started in three ways:

  • based on the data directly delivered to the application, e.g. by scanning a QR code or decoding a universal link;
  • based on an encrypted push message received from the nextAuth server;
  • through an AppLogin.

The first two ways are relevant when using the app as an authenticator to a website or to other apps. The AppLogin option allows logging in into the app itself and allows securely accessing backend resources using the session for which the user logged in.

Info

Another option for securely accessing backend resources is making use of the Data Service (which starts a headless session). Note that in this case, only the device of the user is authenticated and not the user themself.

Transactions⚓︎

Transactions record an approval (signature) of the user. Transaction signing can be started in two ways:

  • based on the data directly delivered to the application, e.g. by scanning a QR code or decoding a universal link (server-initiated);
  • a transaction signature can also be initiated from the app.

Transaction signatures differ in a couple of ways from a login:

  • a transaction signature is a one-shot approval, no session is associated with a transaction;
  • transaction signatures always requires second factor verification;
  • one can specify second factor requirements;
  • a full audit trail is kept for transactions, i.e. non-repudiable proof that a user signed the transaction from a given device, with a given second factor, at a given time.