How Single Sign-On Works: Trust Storage, Validation, and Secure Implementation
This article explains the concept of Single Sign-On (SSO), why it’s essential for large web platforms, the core steps of storing and validating trust, common cookie‑based approaches, their security drawbacks, and how server‑side solutions using distributed caches and digital signatures can provide a robust, cross‑domain authentication system.
Single Sign-On (SSO) means that in an environment with many coexisting systems, a user logs in once and does not need to log in again to other systems; the initial login grants trust to all other systems.
SSO is widely used in large websites such as Alibaba, where hundreds of subsystems cooperate during a single user operation or transaction. Requiring authentication for each subsystem would overwhelm both users and the subsystems.
The implementation of SSO focuses on two key problems: how to generate and store the trust relationship, and how other systems verify its validity.
The essential steps are:
Store the trust
Validate the trust
The simplest way to achieve SSO is to use a Cookie. The following diagram illustrates the basic cookie‑based flow:
However, storing trust in a client‑side Cookie raises two concerns:
Cookies are insecure
They cannot achieve cross‑domain seamless login
Encryption can mitigate the first issue, but the second is a fundamental limitation. Alternatives such as Flash’s Shared Object API can also store trust on the client, but the preferred approach for large systems is to store trust on the server.
Server‑side storage moves the trust relationship to a dedicated SSO system, which introduces three main challenges:
Efficiently storing large amounts of temporary trust data
Preventing tampering of the data during transmission
Ensuring the SSO system trusts both the login system and the systems that rely on SSO
Solutions include using a distributed cache like memcached for scalable temporary storage, applying digital signatures (e.g., certificates or MD5‑based tokens) to protect data integrity, and employing a whitelist so that only approved systems can request or receive trust relationships.
These techniques provide a practical implementation of SSO, but it is important to recognize that SSO itself is not a high‑tech invention; it is simply a set of mechanisms to solve repeated authentication across multiple systems.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
21CTO
21CTO (21CTO.com) offers developers community, training, and services, making it your go‑to learning and service platform.
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.
