Session Management

Session management lets users stay signed in across applications and devices. This guide explains how sessions relate to OAuth 2.0 and OpenID Connect in cidaas, and points you to the right flows for validation, logout, and native-to-web handoff.

Overview

Session management is about the identity provider’s browser session (cookies), instance-wide SSO, and how that interacts with per-client tokens (access, refresh, ID).

This guide explains:

• Concepts — access tokens, refresh tokens, ID tokens, sessions, and cookies
• Single Sign-On (SSO) — how one login covers multiple apps on the same cidaas instance
• Refresh tokens — when to use token-based renewal instead of (or alongside) cookies
• Native-to-web session transfer — when the system browser has no SSO cookie; use a short-lived Session Transfer Token (STT) instead of putting tokens in URLs
• Checking session validity — prompt=none, Check Session iframe, or JWT validation
• Logout — ending the IdP session and related client sessions

Topic	Guide
Validate JWTs (access / ID tokens)	Validate Token
Real-time session checks in the browser	Check Session iFrame
RP-initiated and OIDC logout	End Session (Logout)
STT grant + authorization with stt and PKCE	Session transfer (native to web)

Key concepts

Before going deeper, these terms are used throughout OAuth/OIDC and cidaas:

Term	Description	Configuration
Access Token	Short-lived credential for resource APIs.	Client-specific
Refresh Token	Long-lived credential used to obtain new access tokens without a new user login (when allowed).	Client-specific
ID Token	OpenID Connect JWT with identity claims about the user.	Client-specific
Session	Server-side authenticated state for a device + browser, usually tied to cookies on the IdP domain.	Instance-specific
Cookie	Browser store for the session identifier on the cidaas host.	Browser-based

Understanding sessions

A session is the user’s authenticated state at the identity provider. It is not the same as a single app’s tokens: it is what makes SSO possible across clients that use the same cidaas instance.

Sessions are:

• Device- and browser-specific — each browser profile has its own session
• Time-limited — controlled by session lifetime and inactivity rules
• Cookie-based — the browser sends the session cookie on redirects to cidaas

Single Sign-On (SSO)

Single Sign-On means the user authenticates once; later, other applications on the same cidaas instance can complete authorization without showing the login form again, as long as the session is still valid.

How SSO works

1. The user logs in to an application via cidaas.
2. cidaas creates a session and sets a cookie in the browser.
3. The user opens another application that uses the same instance.
4. That app sends the user to cidaas (authorization request).
5. cidaas validates the session cookie; if valid, the user is signed in without re-entering credentials.
6. cidaas returns to the app with an authorization code or tokens, depending on the flow.

Session cookies

cidaas session management relies on HTTP cookies. A cookie carries a session identifier, is scoped to the IdP host, and respects expiration rules you configure.

Cookies let the browser stay “known” to cidaas across navigations and apps that redirect through the same host.

Session expiration

Two common levers (names may match your tenant settings):

Setting	Description
Session lifetime (session_lifetime_in_seconds)	Upper bound on how long the session may exist, regardless of activity.
Session inactivity timeout (session_inactivity_timeout_in_seconds)	If the user does not use any app that touches this session for that long, the session ends.

What causes session expiration?

Event	Effect
Logout	Session ends; cookies cleared as part of logout handling.
Password reset	Session often invalidated (security).
Lifetime reached	User must sign in again.
Inactivity timeout	Session ends if idle too long.
Prechecks / conditions not met	Session cookies may be reset until requirements are satisfied.

Remember Me

If your product uses Remember Me:

• Hosted pages may send rememberMe: true on login.
• If the app sets is_remember_me_selected, cidaas may treat the user as wanting a longer-lived experience when rememberMe is omitted.
• rememberMe: false can avoid setting the SSO cookie so each app may require a fresh login.

Refresh tokens

Refresh tokens are useful when cookie-based SSO is not available or not enough:

• Native mobile or desktop apps
• Devices and IoT
• Scenarios that need offline or long-lived access without relying on the browser IdP session

Refresh token vs. session management

Aspect	Refresh tokens	Session (SSO)
Typical use	Native, offline, non-browser	Web, same browser redirects to IdP
Mechanism	Token endpoint + refresh_token grant	Cookie on IdP
Scope	Per client	Instance-wide browser session
Lifetime	Per client / rotation policy	Instance session settings
Revocation	Per refresh token	Whole session (affects SSO for that browser)

How to get a refresh token

Request the offline_access scope in your authorization request:

GET /authz-srv/authz?
  response_type=code&
  client_id=your_client_id&
  redirect_uri=your_redirect_uri&
  scope=openid profile offline_access

Using refresh tokens

When an access token expires, call the token endpoint:

POST /token-srv/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&
refresh_token=your_refresh_token&
client_id=your_client_id&
client_secret=your_client_secret

After a successful refresh, assume refresh token rotation: the old refresh token should not be reused.

Note: For many web apps, SSO via session is the main experience; use refresh tokens where cookies cannot carry the session or you need offline-style renewal.

Native app vs. browser SSO (session transfer)

If the user is signed in in the app but the system browser has no cidaas session, opening a web URL will not get SSO. Do not pass long-lived tokens in query strings.

Typical reasons: WebView vs system browser (no shared cookie), device code then opening the web, or refresh tokens still valid in the app while the browser IdP session has already timed out (timeboxed web session vs. longer-lived refresh). Use session transfer (short-lived STT + authorization with PKCE). See Session transfer (native to web) for motivation, examples, and steps.

Validating sessions

You may need to know whether the user still has a valid IdP session or valid tokens.

1. Silent authorization check (prompt=none)

Repeat the authorization request with prompt=none:

GET /authz-srv/authz?
  response_type=code&
  client_id=your_client_id&
  redirect_uri=your_redirect_uri&
  prompt=none

• Session still valid: redirect to redirect_uri with code or tokens (depending on response_type).
• Not valid: error such as login_required.

Useful for occasional checks; involves a redirect.

2. Check Session iframe (advanced)

For frequent checks without full redirects, use the OIDC check session iframe and postMessage. See Check Session iFrame.

3. Token validation

Validate JWT access or ID tokens (signature, exp, aud, iss, etc.). See Validate Token.

Ending sessions (logout)

To sign the user out of the IdP session and align with OpenID Connect logout patterns, use the end session endpoint and related configuration. See End Session (Logout).

Related topics

• OAuth2 basics
• Access token / ID token claims
• Session transfer (native to web)
• Validate Token
• Check Session iFrame
• End Session

Need Support?

Please contact us directly on our support page.