How to Implement Robust Single Sign-On Across Multiple Domains

1. Shared Session

Sharing Session is the most direct and simple way to achieve SSO. User authentication info is stored in the Session and used as credentials. This works well within a single site, but in scenarios where authentication, user management, and business applications are separated, challenges arise. For simple architectures with few subsystems, Session sharing can be considered.

This architecture uses a Redis‑based Session sharing solution. Sessions are stored in Redis, and the global cookie domain is set to the top‑level domain, allowing the SessionID to be shared across subsystems.

However, this approach has serious scalability issues. ASP.NET Session storage requires a SessionStateItemCollection object, which is serialized and encrypted. When a user accesses the application, the entire content is deserialized, imposing constraints:

All types used in the Session must be shared across subsystems (identical assemblies and types), limiting Session usage.

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

2. OpenID‑Based SSO

This method simplifies user identity to an OpenID stored on the client. When a user logs into a subsystem, the OpenID is sent to the server, which constructs authentication information. It is commonly used in hybrid C/S and B/S systems. The flow is:

User logs in for the first time, sending 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 user authentication information to the subsystem.

The subsystem builds the user verification data and returns authorized content to the client.

This mechanism decouples the Session sharing issues but relies on storing OpenID on the client, which is difficult in pure B/S models.

3. Cookie‑Based OpenID Storage

Cookies act as carriers between server and browser. Since cookies are scoped by domain, subdomains can access cookies set on the parent domain. By using a top‑level domain cookie to hold the OpenID, subsystems can share it.

The verification steps are similar to the previous method:

Log in on the authentication service site.

Write the OpenID into the top‑level domain cookie.

Access a subsystem (cookie contains OpenID).

The subsystem extracts the OpenID and sends it to the authentication service.

The service returns authentication information.

Authorized content is returned to the client.

While this solves type‑dependency issues, it assumes all subsystems share the same top‑level domain, which is not always true in production.

4. SSO in B/S Multi‑Domain Environments

When multiple top‑level domains are involved, OpenID cannot be shared directly. A JSONP approach can be used to handle cross‑domain SSO.

The verification steps are:

User logs into a subsystem.

The subsystem records login state and OpenID.

User accesses a business subsystem.

If not logged in, the user is 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; the business subsystem constructs a login credential.

The login result is returned to the login subsystem, which redirects the user back to the business subsystem.

Authorized content is returned to the client.

5. Security Considerations

In cross‑domain SSO, storing OpenID in the user table raises security and scalability concerns. OpenID appears on the client, so it needs an expiration mechanism. Refreshing OpenID on one terminal invalidates others, causing a conflict in multi‑terminal scenarios.

The solution adopted is a “single user, multiple OpenIDs” approach: each login generates a new OpenID stored in Redis with an expiration time, allowing multiple terminals to have distinct OpenIDs without affecting each other.

Source: http://blog.csdn.net/qq_24084925/article/details/52230423