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.

21CTO
21CTO
21CTO
How Single Sign-On Works: Trust Storage, Validation, and Secure Implementation

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:

SSO flow diagram
SSO flow diagram

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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Authenticationdistributed cacheCookieSSOSingle Sign-On
21CTO
Written by

21CTO

21CTO (21CTO.com) offers developers community, training, and services, making it your go‑to learning and service platform.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.