Understanding Single Sign-On (SSO) Mechanisms: Shared Session, OpenID, Cookie, and Cross‑Domain Solutions

Note: Single sign‑on (SSO) is an important knowledge point often asked in interviews; this article briefly introduces its principles to help readers understand the concepts.

SSO is widely used in modern system architectures to unify authentication across multiple subsystems, but different application environments may require different implementation schemes.

1. Shared Session

Sharing the session is the most direct and simple way to achieve SSO. User authentication information is stored in a session (used as a credential). In a simple architecture with few subsystems, the session can be stored in Redis and a global cookie domain set to the top‑level domain, allowing the SessionID to be shared across subsystems.

This approach has serious scalability issues: ASP.NET session storage requires the SessionStateItemCollection object, which is serialized and encrypted. When a user accesses the application, the entire session content must be deserialized, imposing two constraints:

All types used in the session must exist in every subsystem (identical assemblies and types), limiting flexibility.

Cross‑top‑level‑domain scenarios cannot be handled.

2. OpenID‑Based SSO

This method simplifies the user identifier to an OpenID stored on the client. After the first login, the client receives an OpenID from the authentication service; subsequent subsystem requests include this OpenID, which the subsystem forwards to the authentication service to obtain user verification information. The flow is more suitable for C/S combined systems.

The main issue is that OpenID is stored on the client in a C/S architecture, making it difficult to apply in pure B/S scenarios.

3. Cookie‑Based OpenID Storage

Cookies act as carriers between server and browser. By using a top‑level domain cookie, the OpenID can be shared among subdomains (e.g., a.xxx.com and b.xxx.com can access a cookie set for xxx.com). The verification steps are similar to the OpenID method, but the OpenID is written into the top‑level domain cookie.

This approach decouples the type constraints of shared sessions, but it assumes all subsystems share the same top‑level domain, which is not always true in production.

4. B/S Multi‑Domain SSO Handling

When subsystems reside under different top‑level domains, OpenID cannot be shared directly. JSONP is used to transfer the OpenID between systems, enabling cross‑domain authentication.

The verification steps involve the user logging into a subsystem, recording login state and OpenID, using JSONP to pass the OpenID to a business subsystem, which then calls the authentication service to obtain credentials and finally returns the authorized content to the client.

5. Security Issues

Storing OpenID on the client raises security and scalability concerns. A single OpenID per user can cause conflicts when multiple devices are used because refreshing the OpenID on one device invalidates it on others.

The article proposes a solution of generating multiple OpenIDs per user: each login creates a new OpenID stored in Redis with an expiration time, allowing different terminals to operate independently without invalidating each other.