What is a Single Sign-On Session? A Brief Overview

An Introduction to Sessions and SSO

Single Sign-On (SSO) sessions are not web sessions - how do you tell them apart?

When designing your SSO solution and making architectural decisions, you need to be aware of the difference between the session on each website or client and the SSO session that the identity server maintains.

This article discusses the SSO session, how it differs from the website session, and some important points to keep in mind when designing your SSO solution.

Overview of the SSO process

The basic SSO process, stripped of most details, is fairly simple:

What you should notice here is that website session and the SSO Session are different things, and will have different lifetimes.

The web session

The web session is entirely on the client side and has to do with requests, responses and cookies that have nothing to do with the authentication or SSO. The web session consists of a user that is actively interacting with a web service. Best practice is to let the web session contain the principal after the user has authenticated with the identity server.

The Curity SSO session

An SSO session (authenticated session) is a result on the server after a successful authentication. It contains information about:

• How the user authenticated (which authenticator)
• When the user authenticated
• Details about the user that authenticated

When an authentication request arrives at the server, Curity will check if there is an existing SSO session that matches the requirements for the new request.

The following is then checked:

• Is there a SSO session for the requested authenticator
• Is it recent enough (i.e. expired or the client requested a max_age)
• Did the client allow SSO to be used.

The SSO session can only be read by Curity, but it is used to construct the token that will be returned to the client as proof of authentication. In OpenID Connect, that is an ID Token.

Keeping SSO sessions apart

A major benefit of using Curity is that even though the SSO session is separated from the web session, it is still connected to the client via the OpenID Connect protocol. Curity maintains the SSO sessions on the server and when a client requests authentication it uses the SSO session if applicable to authenticate the user and produce an ID Token that the client (web site) will receive. Each client receives different tokens even though the underlying SSO session may be the same.

Cross domain SSO

The real benefit of SSO comes when an organization has multiple sites on different domains. The goal is to achieve a seamless user experience between these sites. The SSO session serves as the vault where the login information is kept, and OpenID Connect is the key to communicate with the vault to get identity information.

As the diagram shows, this allows for cross domain, and even cross-organization single sign on. No cookies flow between the sites, only protocol tokens.

Separated sessions

By separating authenticated sessions - letting the initial login or authentication be split into a number of different sessions - you can make the application keep the session alive for lower valued assets, while still requiring a full login when higher value assets are requested.

This will allow for different behavior while maintaining the the same web session (or allowing multiple different web sessions) for the user.

Curity Solution

In the Curity Identity Server, the management of the SSO session is contained, and does not allow information to cross over between domains. Each authentication profile has its own SSO session namespace, and cross-breeding is not allowed. This allows for virtualization of the authentication service for larger organizations with many disparate brands.

More information

For more information, see the Curity Developer Portal.

Published: 2019-03-14

Curity