Mastering SSO: Session Sharing, OpenID, and Cross‑Domain Strategies

Single Sign‑On (SSO) is widely used in modern system architectures to unify authentication across multiple subsystems, providing a single entry point for many applications.

1. Shared Session

Sharing the Session is the most direct and simple SSO method. User credentials are stored in a Session object, which can be used across subsystems when the system is small and the number of sub‑systems is limited. The author implemented a Redis‑backed Session sharing scheme and set a top‑level cookie domain so that the SessionID can be accessed by all sub‑systems.

This approach has serious scalability issues:

The types stored in the Session must be common to all sub‑systems, imposing strict assembly and type constraints.

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

2. OpenID‑Based SSO

In this model the user’s identity is reduced to an OpenID stored on the client. When a user logs into a subsystem, the OpenID is sent to the server, which reconstructs the user’s authentication information. The flow is:

User sends username/password to the authentication service.

The service returns an OpenID to the client.

The client stores the OpenID.

When accessing a subsystem, the client sends the OpenID.

The subsystem forwards the OpenID to the authentication service.

The service returns the user’s authentication data.

The subsystem builds the user’s verification info and returns the authorized content to the client.

This decouples the authentication from Session sharing, making the system more flexible.

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 sub‑systems under the same domain. The verification steps are similar to the OpenID method, but the OpenID is written into the top‑level cookie after login.

While this solves the type‑compatibility issue of shared Session, it assumes all sub‑systems share the same top‑level domain, which is often not true in production.

4. Cross‑Domain SSO for B/S Multi‑Domain Environments

When multiple top‑level domains are involved, OpenID cannot be directly shared. The article proposes using JSONP to transfer the OpenID across domains. The steps are:

User logs into a login subsystem, which records login state and OpenID.

User accesses a business subsystem; if not logged in, they are redirected to the login subsystem.

The login subsystem sends the OpenID to the business subsystem via a JSONP interface.

The business subsystem calls the authentication service with the OpenID.

The service returns authentication data, which the business subsystem uses to construct a user credential.

The result is returned to the client.

5. Security Considerations

Because OpenID resides on the client, it must have an expiration mechanism. The author adopts a “single user, multiple OpenIDs” strategy: each login generates a new OpenID stored in Redis with an expiration time, allowing multiple terminals to have independent OpenIDs without invalidating each other.