Skip to content

Sessions⚓︎

The Mobile SDK has a concept of authenticated sessions. Each login and enrolment has a session associated with it. Just like a [Flow] (..flows/flows.md), a session has a lifecycle. Note that a session is implicitly started by a flow, but it can outlive the flow (which stops when all user interaction is taken care off).

A new session has as Status STARTING. The status will change to USER_INTERACTION and transition to ACTIVE if the flow was successful. A session has two terminal statuses: DONE, indicating that the session is terminated, and ERROR, indicating that the session was terminated with an error;

As long as the flow is active, no SessionUpdate callbacks will be sent out. Note that the FlowUpdate callback also contain the session. If an error occurs that would terminate the session while the flow is active, it will be communicated with a FlowUpdate callback, containing the specific error.

When the flow is no longer active (and has not terminated in an error), one could listen for SessionUpdate callbacks for updates to the session's Status. This is mainly useful for continuous logins and AppLogin scenarios, where one would like to give feedback to the user when that login has expired and possibly redirect the user to a login screen.

A session can be stopped at any time by calling the stop() method on that session:

java NextAuth.getSessionManager().stop(session);

NextAuth.default.stop(session)

Session Properties⚓︎

Each session has a status (which indicates in which of the five states the session currently is) and a history status. It also indicates whether or not it concerns a registration flow and/or an AppLogin. In case of an AppLogin, the session also contains the necessary information for starting an authenticated web session towards the associated backend, directly from inside the app.

Furthermore, sessions can contain announce info (information meant to be displayed towards the user when confirming or inputting a second factor) and session info (information meant to be displayed towards the user after being logged in) if this was supplied during the setup of the external authentication (i.e., the provided UserContext in getQRLogin, for example).

History Status⚓︎

Each session can have a history status:

  • Upon successful login, the history status is set to LOGGED_IN (for continuous sessions, i.e. sessions where pingTime > 0) or LOGGED_IN_ONE_SHOT (for one shot authentications, i.e. a pingTime = 0) status. Afterwards, when the user logs out or is logged out from a continuous session (pingTime > 0), the history status changes to LOGGED_OUT.
  • When the user denied the login or the login has timed out, the history status is set to ABORTED.
  • If an error occurred during the authentication process, the history status is set to ERROR.