Session Management
In a digitized world, there will be multiple digital channels (or single-page applications) to engage users and provide them various benefits. Enabling a single sign-on is one of the highest priorities for allowing seamless user interactions across all channels. Session Management allows users to stay securely logged in on a specific device and browser.
Basic Terminology
| Term | Description | Configuration |
|---|---|---|
| session |
A user session defines the information of the device that holds a session for the user which is independent of the channel. Its validity is based on the expiration time defined by the parameters session_lifetime_in_seconds and session_inactivity_timeout_in_seconds.
|
instance-specific |
cidaas implements Session Handling using cookies to maintain a user's Authentication Session across web requests.
A cookie typically contains two bits of data, a unique ID for each user, and a site name.
It enables a website to retrieve these values when a user revisits it to help remember the user and keep them logged in. This eliminates further prompts when the user switches applications during a particular session. A new session cookie is created for every new session on the same or different device where the application is running.
You can set additional restrictions to a specific domain and path to limit where the cookie is sent.
This is done using the domain attribute.
Domain Attribute
The domain attribute specifies which hosts are allowed to receive the cookie. If this attribute is unspecified, it defaults to the same host that set the cookie, excluding the subdomains.
How domain-specific cookies work?
They work based on the following rules.
1. The origin domain of a cookie is always the domain of the originating request.
2. If the origin domain is an IP, then the cookie's domain attribute must not be set.
3. If a cookie's domain attribute is not set, the cookie is only applicable to its origin domain.
4. If a cookie's domain attribute is set,
- The
cookieis applicable to thatdomainand all its subdomains. - The cookie's
domainis the same as theorigin domainor its parent. - The cookie's
domainis not a top-level domain, public suffix, or a parent of a public suffix.
Session Expiration and Extension
On cidaas, a session has its own expiration date. For this, there are two parameters configurable on cidaas, session_lifetime_in_seconds and session_inactivity_timeout_in_seconds.
1. After the expiration date which is based on session_lifetime_in_seconds is over, the session is overdue and no token will get renewed. Depending on prompt which is overhanded as the query parameter in the authz (authorization URL) call, one of the following outcomes occur.
prompt=none: This will redirect to the overhanded redirect URL which is provided in the query parameter.- Otherwise, the user will be redirected to the login page determined by the
clientId.
2. 
NOTE: The session is NEVER extended, but it relates to the useractivity parameter which denotes that the session is still valid until the expiration date.
3. session_inactivity_timeout_in_seconds defines when a session loses its validity due to the user's inactivity. useractivity is defined by a successful authz call. This also means session_lifetime_in_seconds > session_inactivity_timeout_in_seconds.
4. A session also expires when a user logs out or resets the password.
The Role of Session vs. Token
Session tokens serve to identify a user’s session within the HTTP traffic exchanged between the application and its users.
The expiration time of tokens and refresh tokens is completely independent of a session. Also, getting a new token using a refresh token will not extend the user's session. Rather, a new access token is created when the authz call is made with the correct overhanded parameters that uniquely define a session.
Session Management Tokens
| Term | Description | Configuration |
|---|---|---|
| access_token |
This is a token provided in each call to verify that someone is allowed to access a resource. It has an expiration time.
|
client-specific |
| refresh_token |
Using a refresh token you can get a new access token for a particular configured expiration time which also creates a new refresh token.
|
client-specific |
Refreshing an Access Token
When the user receives the access token initially, it will include a refresh token and an expiration time.
The presence of the refresh token means that the access token will expire and a new one will be generated for the user without any interaction.
Because OAuth2 access expires after a limited time, an OAuth2 refresh token is used to automatically renew access at the Renewtoken Endpoint.
Single Sign-On Session
SSO, through a browser-side implementation, involves an integration that redirects the user to the cidaas login page.
In cidaas, enabling single sign-on works as illustrated below.
Note: You can set prompt=none and provide a redirect URI in the query parameter to define the URI to which the user will be redirected when a session is invalid or not found.Session Deletion/Deactivation
On cidaas, a session is deleted in the following cases.
When a user resets the password.
When a user logs out of a particular session.
Session deletion will invalidate the cookies that have been set for that session and the corresponding user will no longer be logged in through SSO.
We've come to the end of our discussion for Session Management on cidaas. If you have any questions, please contact our support team for further assistance.
We'll be happy to help. Thank you!