Skip to content

Sessions⚓︎

The Mobile SDK employs a concept of authenticated sessions. Each login and enrolment has a session associated with it. Similar to a Flow, each session has a lifecycle. A session is implicitly started when a flow is created. Although the flow stops as soon as all user interaction is finished, the session can last longer than this.

A new session has 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 was terminated normally, 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 contains the session. If an error occurs that would terminate the session while the flow is active, this fact will be communicated with a FlowUpdate callback containing the specific error.

When the flow is no longer active (and has not terminated with an error), you can listen for SessionUpdate callbacks to be notified of updates to the session’s Status. This is mainly useful for continuous logins and AppLogin scenarios, where it is customary to give feedback to the user if a login has expired and possibly redirect them back 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, as well as a history status. The session also indicates whether it involves a registration flow and/or an AppLogin. In case of an AppLogin, the session also contains the information that is needed to start an authenticated web session towards the associated backend directly from inside the app.

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

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. where pingTime > 0) or LOGGED_IN_ONE_SHOT for one-shot authentications (i.e. where pingTime = 0). Afterwards, when the user logs out or is logged out from a continuous session, the history status changes to LOGGED_OUT.
  • When the user denies the login or the login times out, the history status is set to ABORTED.
  • If an error occurs during the authentication process, the history status is set to ERROR.