Implementing Single Sign-On (SSO) in B/S Systems: Cookie, Authentication Center, and LocalStorage Approaches

Preface

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 keep (Session ID or Token) and send with every subsequent request. Cookies are the most convenient way to store these identifiers.

Single Sign‑On (SSO) allows 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 a Session, it can be shared by serializing the Session to Redis so that all applications read the same Redis store.

However, because different applications have different domains, a Session ID stored in a browser cookie is limited to its domain and cannot be automatically sent to other domains, which is the core challenge of SSO.

Implementation 1: Parent‑Domain Cookie

Cookie scope is determined by the domain and path attributes. Setting domain to a parent domain makes the cookie shared by all sub‑domains.

By storing the Session ID or Token in a cookie whose domain is the main domain (e.g., baidu.com ) and path is / , all sub‑domains (e.g., tieba.baidu.com , map.baidu.com ) can access the same cookie, achieving SSO.

Summary: Simple to implement but does not work across different primary domains.

Implementation 2: Authentication Center

Deploy a dedicated authentication center that handles login requests. Users log in to this center, which records the login state and writes a Token into its own cookie (the application cannot read this cookie directly).

If an application receives a request without a Token, it redirects the user to the authentication center. The center, using its cookie, determines whether the user is already logged in; if so, it generates a Token, appends it to the target URL, and redirects back.

The application then validates the Token with the authentication center, records the login state, writes its own Token cookie, and grants access. Subsequent requests from the same application automatically include this Token.

Open‑source examples: Apereo CAS (enterprise‑grade) and XXL‑SSO (simple, not security‑hardened).

Summary: More complex, supports cross‑domain, and offers good extensibility – the standard SSO approach.

Implementation 3: LocalStorage Cross‑Domain

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

The front‑end can write the Token to its own localStorage and, using an invisible iframe plus postMessage() , propagate the same Token to other domains' localStorage . Each request to the back‑end then includes the Token from localStorage .

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);

This front‑end‑only solution requires almost no back‑end changes and also works across domains.

Summary: Fully controlled by the front‑end, minimal back‑end involvement, and supports cross‑domain sharing.

Supplement: Domain Hierarchy

From a technical standpoint, .com and .cn are top‑level domains, .com.cn and baidu.com are second‑level, tieba.baidu.com is third‑level, and so on. In practice, the term “primary domain” is used to refer to the top‑level domain that can be independently registered.