Sessions

Session stores persist user authentication state and determine how the Orchestrator tracks authenticated users between requests. Sessions are independent of caches — caches store connector tokens and provider data, while sessions store user authentication state.

​

How Sessions Work

The Orchestrator maintains server-side session state for each authenticated user. When a user authenticates, the Orchestrator creates a session containing their authentication state, tokens, and user attributes, then returns an opaque session cookie to the browser. On subsequent requests, the cookie identifies the session — all sensitive data stays server-side, never in the cookie itself.

​

Sessions and the Authentication Lifecycle

Sessions are created as part of the authentication flow and directly affect how users experience subsequent requests across all Orchestrator modes.

​

When Sessions Are Created

A session is created after successful authentication in any Orchestrator mode. The Orchestrator stores the user’s authentication state (which IdP authenticated them, when the authentication occurred), tokens received from upstream providers, and enriched attributes loaded from attribute providers. This all happens server-side — only an opaque session cookie is sent to the client.

​

How Sessions Affect Subsequent Requests

On subsequent requests, the Orchestrator checks for a valid session cookie. If a valid, non-expired session exists, the user is not redirected to the IdP again — the Orchestrator uses the stored session data to fulfill the request (inject headers, issue tokens, serve LDAP entries). This is why session lifetime and idle timeout directly affect how often users must re-authenticate.

​

Per-Mode Session Behavior

Each Orchestrator mode interacts with sessions differently:

• HTTP Proxy — The session cookie is set on the proxy domain. Every proxied request checks the session. If the session is expired, the user is redirected to the IdP for re-authentication.
• OIDC Provider — The session manages authorization server state. Token refresh can extend the effective session without requiring user interaction, as long as the session itself has not expired.
• SAML Provider — The session manages IdP state. New SAML AuthnRequests check the existing session before redirecting to the upstream IdP. If a valid session exists, the Orchestrator can issue a SAML assertion without re-authenticating the user.
• LDAP Provider — Sessions are per-connection bind state, not cookie-based. Each LDAP connection maintains its own authenticated context that lasts for the duration of the connection.
• AI Identity Gateway — Sessions are token-based (OAuth), not cookie-based. Token expiry drives re-authentication rather than session cookie expiry.

​

Session Expiration and Re-Authentication

When a session expires (either maximum lifetime reached or idle timeout exceeded), the next request triggers re-authentication. The user is redirected to the upstream IdP. If the IdP has its own active session (SSO), re-authentication may be transparent to the user — they are redirected to the IdP and back without seeing a login prompt. If the IdP session has also expired, the user sees a login prompt. For a complete overview of how authentication flows across all Orchestrator modes, see How Authentication Works.

​

Session Security

Maverics sessions are designed for zero-trust environments:

• 256-bit session IDs — Generated using cryptographically secure random number generators (CSPRNG), providing 2²⁵⁶ possible session IDs. Exceeds OWASP’s minimum 64-bit entropy requirement with zero predictability between sessions.
• Secure cookies by default — HttpOnly (no JavaScript access), Secure (HTTPS only), and SameSite=None (cross-site auth flows) are all enabled by default. These protect against session hijacking, XSS, and CSRF attacks.
• Server-side storage — The session cookie is an opaque identifier only. User attributes, authentication state, and metadata are stored on the server, not in the cookie.
• Automatic expiration — Sessions expire based on configurable maximum lifetime and idle timeout. Expired sessions are automatically purged from storage.

​

Session Lifetime

Sessions support both maximum lifetime and idle timeout controls:

• Maximum lifetime — The total time a session can exist after authentication, regardless of activity. Default: 12 hours.
• Idle timeout — Time a session can remain inactive before expiring. Disabled by default.
• Dynamic expiration — Service Extensions can evaluate session lifetime and idle timeout dynamically, enabling role-based or context-aware timeout policies (e.g., shorter timeouts for contractors, longer for employees).
• Single logout — When a session expires or is explicitly terminated, all session data is deleted and the cookie is invalidated. Users must re-authenticate through the full authentication flow.

​

Session Store Types

The session store type determines how sessions are managed across your deployment. The local session store is the production-recommended option — for single-node deployments it works with no additional configuration, and for multi-node deployments, sticky sessions (session affinity) on the load balancer route each user to the same Orchestrator instance (configure cookie-based affinity on the maverics_session cookie). Sessions are stored in-memory with LRU eviction and are lost on restart.

​

Store Options

​

Session Detail Pages

​

Cross-Reference

Configuration details for session cookie, lifetime, and store settings are on each sub-page: Local Sessions and Cluster Sessions.

​

Related Pages