# How frontend sessions work

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

A "frontend" IDP session is created by Mosaic when a user logs into the app using redirect-based athentication method or with a hosted login.

Such IDP session is bound to a specific user. Mosaic creates a client-side cookie that is used to track the IDP session. The IDP session is active until it expires, unless terminated before (see [Session lifetime](/guides/user/how_sessions_work#session-lifetime)).

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. Authentication is also required if the session doesn't fulfill the session criteria. Once the IDP session is over, the app may rely on the current authentication 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

Every user authentication creates a new session and returns an access token, ID token, and refresh token (if `offline_access` was requested). 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](/guides/user/resources_overview) can be accessed and the user's [roles](/assets/how_rbac_works.7cee3148599268ede83dd25eae3fa0e10ba721d651fbc6907ff4225545211c28.71fe162d.md) to determine their permissions.

## Session lifetime

By default, the session is valid for 2 weeks, and it can be configured up to 1 year in the client settings. The session gets extended every time new access tokens are issued during the session lifetime.

A session terminates if the end-user initiates an IDP logout using the [Logout API](/openapi/user/one-time-login.openapi/other/logout) or [Terminate sessions API](/openapi/user/oidc.openapi/other/endoidcsession). These will delete all the sessions for the relevant user. An admin can revoke the session using the [Revoke sessions API](/openapi/user/sessions.openapi/other/deleteusersessions). The session revocation call will delete all the sessions for the specified user, as well as revoke all refresh tokens.

Note
For OIDC-based sessions, configure the IDP session lifetime in the client settings. The "session expiration" setting configured in resources corresponds to the maximum period of time the refresh token can be rotated for that resource.

## Session cookie

Mosaic creates a session cookie that stores the information needed to obtain user access and authorization, without requiring the user to authenticate. 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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#security))
- 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