How Single Sign-On (SSO) Works: Storing and Validating Trust

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 single login is trusted by all other systems.

SSO is used extensively in large websites such as Alibaba, where hundreds of subsystems cooperate on a single user transaction. Requiring authentication for each subsystem would overwhelm users and complicate the subsystems.

The essence of implementing SSO is to solve how to generate and store the trust relationship and how other systems verify its validity. The key points are:

Store trust

Validate trust

Once these problems are solved, the desired SSO effect is achieved. The simplest way to implement SSO is using cookies, as shown in the diagram below.

This approach stores the trust in a client‑side cookie, which raises two concerns:

Cookies are insecure

Cross‑domain login is not possible

The first issue is usually addressed by encrypting the cookie. The second issue is a hard limitation; the idea of storing the trust relationship on the client can also be realized with technologies like Flash’s Shared Object API.

In practice, large systems tend to store the trust relationship on the server side, as illustrated in the following flow.

The server‑side approach moves the trust storage to a dedicated SSO system, but several critical problems must be solved:

How to efficiently store large amounts of temporary trust data

How to prevent tampering of information during transmission

How to make the SSO system trust both the login system and the SSO‑enabled systems

For the first problem, a distributed cache solution similar to Memcached can provide scalable storage and fast access. For the second problem, digital signatures are commonly used—either via certificates or MD5 hashing. The SSO system signs the parameters when returning the SSO URL, includes a token, and the receiving system validates the token to detect any tampering. For the third problem, a whitelist mechanism is employed: only systems on the whitelist can request or receive trust relationships, effectively controlling which systems can participate in SSO.

These are simple implementation techniques; SSO itself is not a high‑tech concept but a set of solutions to specific trust and authentication challenges. Understanding this helps deepen exploration of SSO.

Source: cutesource URL: http://blog.csdn.net/cutesource/article/details/5838693