Implementing Single Sign-On (SSO) in Web Applications: Cookie, Authentication Center, and LocalStorage Approaches

前言

In B/S systems, login is usually based on cookies; after a successful login the session state is stored in a Session or a Token, which the client must send with each request. Cookies are the most convenient way to persist the Session ID or Token, allowing the server to verify login status.

Single Sign‑On (SSO) enables a user to log in once and access multiple trusted applications under the same account platform, such as Baidu Tieba and Baidu Maps.

The essence of SSO is sharing login state across applications. If the state is kept in Session, it can be shared by serializing the Session to Redis so that all applications read the same Redis data.

However, different applications usually have different domain names, and Session IDs stored in browser cookies are scoped to their domain, preventing cross‑domain transmission. The key to SSO is sharing the Session ID or Token across domains.

实现方式一：父域 Cookie

Cookie scope is determined by the domain and path attributes. Setting domain to a parent domain makes the cookie a “parent‑domain cookie”, which is automatically shared with sub‑domains.

By setting the cookie’s domain to the common root domain (e.g., baidu.com ) and path to / , all sub‑domains (e.g., tieba.baidu.com , map.baidu.com ) can access the same cookie, achieving SSO. This method is simple but does not work across different top‑level domains.

实现方式二：认证中心

Deploy a dedicated authentication center as an independent web service that handles login requests.

Users log in at the authentication center, which records the login state and writes a Token into a cookie that only the authentication center can read. When an application receives a request without a Token, it redirects the user to the authentication center.

The authentication center, seeing the user’s cookie, knows whether the user is already logged in. If logged in, it redirects back to the target URL with a Token appended; the application then validates the Token with the authentication center, stores its own cookie, and grants access.

Two open‑source authentication‑center implementations are mentioned:

Apereo CAS – an enterprise‑grade SSO system originally from Yale University.

XXL‑SSO – a simple SSO system by a Meituan engineer, not recommended for production.

This approach is more complex but supports cross‑domain scenarios and offers better extensibility.

实现方式三：LocalStorage 跨域

Because modern browsers restrict cookie cross‑domain sharing (especially with the SameSite attribute), an alternative is to store the Session ID or Token in LocalStorage and let the front‑end transmit it with each request.

The front‑end can write the Token into its own LocalStorage and, using an invisible iframe and postMessage() , propagate the same Token to LocalStorage of other domains.

Key code:

// 获取 token
var token = result.data.token;

// 动态创建一个不可见的iframe，在iframe中加载一个跨域HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
// 使用postMessage()方法将token传递给iframe
setTimeout(function () {
    iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
    iframe.remove();
}, 6000);

// 在这个iframe所加载的HTML中绑定一个事件监听器，当事件被触发时，把接收到的token数据写入localStorage
window.addEventListener('message', function (event) {
    localStorage.setItem('token', event.data)
}, false);

The front‑end reads the Token from LocalStorage before each request and includes it, achieving cross‑domain SSO with minimal back‑end involvement.

补充：域名分级

From a technical standpoint, .com and .cn are top‑level domains, .com.cn or baidu.com are second‑level, and tieba.baidu.com is third‑level, and so on. In practice, the “primary domain” refers to a domain that can be independently registered (e.g., baidu.com ), while its direct sub‑domains are considered secondary.

Source: cnblogs.com/yonghengzh/p/13712729.html