How backend sessions work

Sessions track user interactions with a resource within a given time frame.

A "backend" IDP session is created by Mosaic when a user logs into the app using backend-initiated authentication methods or via Journeys. Each IDP session is bound to a specific user. The IDP session is active until it expires, unless terminated before (see Session lifetime).

Backend sessions are created upon backend authentication and can be shared with other backend methods, i.e. you can add multiple authentications to a session. The backend authentication returns an ID of the session which you should store and process on your side. See Manage backend sessions

Typically, both the application session and IDP session are used to determine if the user is authenticated whenever access is requested. Once the application session is over, authentication is always required. Once the IDP session is over, the app may rely on the access token until it expires, but access can no longer be extended without re-authentication.

Note

In our documentation, sessions will refer exclusively to IDP sessions unless stated otherwise.

Tokens and sessions

Backend authentication can create a new session, and receive an access token, ID token, and refresh token from Mosaic. These tokens are bound to the session, user, and client. A valid access token is required to authorize user access to the application, even if there's an active session. The access token (JWT) contains the expiration, user ID, and authorization information—including which resource can be accessed and the user's roles to determine their permissions.

Session lifetime

The session is valid for 2 weeks. Sessions get extended every time new access tokens are issued within the session lifetime.

Note

The session length cannot be customized. The "session expiration" setting configured in resources corresponds to the maximum period of time the refresh token can be rotated.

A session terminates when a logout is requested using the Logout sessions API, which deletes the specific session and revokes the corresponding refresh tokens. In contrast, the Revoke sessions API removes all sessions for the user and invalidates all refresh tokens.

Session cookie

Typically, a session cookie is used to store the information needed to obtain user access and authorization, without requiring the user to authenticate. Upon completing backend authentication, Mosaic creates a session and returns a session ID which you'll need to bind with the app session using cookies. Here are some security guidelines when creating application sessions using cookies:

Security Recommendations
  • Set HttpOnly flags on your cookies to ensure they won't be accessible to JavaScript
  • Set secure flags on your cookies to ensure they are sent only over HTTPS
  • Set the SameSite cookie attribute to Strict if possible (note that this setting might interfere with SSO implementation), and Lax otherwise ( learn more ).
  • Generate new session cookies upon each authentication to prevent session fixation attacks
  • Bind local session ID stored in the cookie to other user or client properties (client IP address, User-Agent, client-based digital certificate, etc.)
  • If possible (also considering your UX requirements), use non-persistent cookies or at least exclude Max-Age or Expires cookie attributes since they will make the cookie persistent
  • Use Cache-Control headers for sensitive content
  • Use Cache-Control: no-cache="Set-Cookie, Set-Cookie2" directive, to allow caching everything except the session ID
  • Logout to invalidate the session