What is a Single Sign-On Session?

When designing your single sign-on (SSO) solution and making architectural decisions, you need to be aware of the differences between the web sessions of websites and the SSO session that the identity server maintains.

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

The 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 identity server, it will check if there is an existing SSO session that matches the requirements for the new request.

The identity server may check things like:

• Is there an 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?

Only the identity server can read the SSO session. It uses the SSO session to construct the token that it will return to the client as proof of authentication. In OpenID Connect, that token is an ID token.

Overview of the Single Sign-On Process

Whenever a user authenticates at the identity server, the identity server creates an SSO session or updates existing SSO sessions which it can use during subsequent authentication attempts, for example, to skip user interaction. The basic SSO process, stripped of most details, is fairly simple:

When a user interacts with a website, site A, and that site requests a token from an identity server, the identity server checks if there is an existing SSO session for the user. If that SSO session meets the current requirements (depending on the request from site A and the policy of the identity server), the identity server can use the SSO session to issue and return the tokens to site A without user interaction. In other cases it will try to update the SSO session to meet the requirements before it returns the tokens.

The website validates any tokens that the identity server returns. If the tokens are valid, the site updates its web session for the user. What you should notice here is that web session at site A and the SSO session at the identity server are two different sessions, and will have different lifetimes.

The Web Session

The web session is entirely on the client side, the website. It is a mechanism that allows the client to correlate multiple requests of a user. While authentication can be part of the web session to identify a user and to personalize the user experience, it is not a requirement for web sessions. A web session can start before authentication without knowing who the user is. The client may, for example, use web sessions to store data for anonymous users such as a shopping cart. In other cases it can also use web session to enable certain features. The web session lives as long as the user is actively interacting with a website. It can therefore live longer or shorter than the SSO session at the identity server.

Cross-domain SSO

The real benefit of SSO comes when an organization has multiple sites on different domains. Cross-domain SSO allows a user to log in once to the identity server in one domain and gain access to applications or services across multiple, separate domains or subdomains without the need to re-authenticate for each one. The SSO session serves as the vault for the login information, and OpenID Connect is the key to communicate with the vault to get identity information.

Site A and site B in the diagram both use the identity server to create their web sessions, but they have different requirements. While the identity server may use an SSO session for site A, site B explicitly enforces (a fresh) user authentication. The diagram also shows that each site maintains its own web session that gives the user access to certain functionality: "the user is logged in to the site".

Sessions with OpenID Connect

Starting Sessions

Even though the SSO session is separated from the web session, it is still connected to the client via the OpenID Connect protocol. The identity server maintains the SSO sessions and when a client requests authentication, the identity server uses an SSO session, if applicable, to authenticate the user and produce an ID token that it returns to the client (website). Each client receives different tokens even though the underlying SSO session may be the same. Clients then use the ID token to create or enrich their web sessions. A best practice is to include the principal from the ID token in the web session after the user has authenticated with the identity server.

Managing Sessions

Clients implement their own session management. It's up to each client to decide how long its web session is valid, when to invalidate or refresh it by requesting a new (ID) token. Different clients can have different requirements with regard to their web sessions. The separation of web sessions and SSO sessions gives clients full control over their web sessions with the user. As long as their web sessions are valid, they can rely on them independently of the lifetime of the SSO session.

Ending Sessions

Since the web sessions and SSO sessions are decoupled, a user (or client) can end any of them without impacting the other. This means for example, that a user can log out at the identity server without being logged out at the client. However, sometimes you want a dependency between the SSO session and a web session, and automatically have users logged out from websites or the identity server when they log out from one or the other. For these cases there are several complements to OpenID Connect namely OpenID Connect Session Management, OpenID Front-Channel Logout, OpenID Connect Back-Channel Logout and OpenID Connect RP-Initiated Logout that allow for tying together the sessions in various ways.

SSO with the Curity Idenity Server

In the Curity Identity Server, the management of the SSO session is contained, meaning you can define trust domains for which an SSO session is valid. Each authentication profile has its own SSO session namespace, and that you cannot cross-breed. This allows for virtualization of the authentication service for larger organizations with many disparate brands.

Last updated: 2025-01-15

Curity