Understanding Single Sign-On (SSO): Why It Is Needed and How It Works
This article explains the necessity of Single Sign-On (SSO) in multi‑system environments, traces its origins from monolithic web applications to distributed clusters, and describes common implementation approaches for same‑domain and cross‑domain scenarios, including the use of a central authentication center such as CAS.
Single Sign-On (SSO) means that after a user logs in once in an environment where many systems coexist, the user does not need to log in again to each of the other trusted systems.
SSO is heavily used in large websites; for example, Alibaba’s ecosystem includes dozens of subsystems, and requiring a separate login for each would overwhelm users and complicate the authentication logic of every subsystem.
Origin of SSO
1. Early monolithic web applications packaged as a single WAR file running on Tomcat stored the logged‑in user’s information in a session , generated a sessionId , and placed it in a cookie that the browser returned on subsequent requests.
When applications were scaled to a distributed cluster (multiple Tomcat instances behind Nginx), each server created its own sessionId . A user logged in on server A could not be recognized on server B, forcing repeated logins and causing session loss when the original session timed out. This inconsistency drove the need for a shared authentication mechanism.
Implementation Methods
1. Same‑domain SSO
When all systems share the same top‑level domain, a login at sso.example.com can set a cookie whose domain is .example.com . All subdomains such as blog.example.com and video.example.com can then read the cookie and consider the user authenticated. This approach is simple but only works within a single primary domain.
2. Cross‑domain SSO
For different primary domains, a dedicated SSO authentication center is deployed (e.g., CAS – Central Authentication Service). All login, logout, user‑info, and status requests are directed to the SSO system, which maintains the user’s session and issues tokens that trusted applications can validate. This architecture supports cross‑domain scenarios and offers better extensibility.
Open‑source projects such as CAS implement the central authentication service model.
Overall, SSO solves the problem of requiring users to authenticate only once while allowing multiple trusted applications to share that authentication state.
Mike Chen's Internet Architecture
Over ten years of BAT architecture experience, shared generously!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.