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

Introduction

In B/S (browser‑server) systems, login is usually implemented with cookies that store a Session ID or a token; the client sends this information with every subsequent request to prove the user is authenticated.

Single Sign‑On (SSO) means that a user logs in once and can access multiple trusted applications under the same account, such as Baidu Tieba and Baidu Maps, without re‑entering credentials.

Implementation Method 1: Parent‑Domain Cookie

Cookies are scoped by the domain and path attributes. By setting the domain to a common parent domain (e.g., baidu.com ) and the path to / , the cookie containing the Session ID or token becomes shared among all sub‑domains, enabling SSO for applications that share the same top‑level domain.

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

Implementation Method 2: Authentication Center

An independent authentication service handles all login requests. After a successful login, the center writes a token into its own cookie. When a user accesses another application, the application redirects to the authentication center; the center checks the cookie, issues a token, and redirects back with the token attached to the URL.

The receiving application validates the token with the authentication center, stores it in its own cookie, and grants access. This method supports cross‑domain SSO and is the standard enterprise approach.

Summary: More complex, supports cross‑domain, highly extensible.

Implementation Method 3: Cross‑Domain LocalStorage

Instead of cookies, the Session ID or token can be stored in the browser’s LocalStorage . The front‑end reads the token from LocalStorage and includes it in each request to the back‑end.

To share the token across different domains, the front‑end creates an invisible iframe that loads a page on the target domain and uses postMessage() to transfer the token, where a script in the iframe writes it into that domain’s LocalStorage . Subsequent requests from that domain can then read the token.

// Get token
var token = result.data.token;

// Dynamically create an invisible iframe loading a cross‑domain HTML page
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
// Use postMessage() to send token to the iframe
setTimeout(function () {
    iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
    iframe.remove();
}, 6000);

// In the loaded HTML, listen for the message and store token in LocalStorage
window.addEventListener('message', function (event) {
    localStorage.setItem('token', event.data);
}, false);

This approach is entirely controlled by the front‑end, requires minimal back‑end changes, and also works across domains.

Summary: Front‑end‑centric, almost no back‑end involvement, supports cross‑domain.

Additional Note: Domain Hierarchy

From a technical standpoint, top‑level domains such as .com or .cn are level‑1, domains like baidu.com are level‑2, and tieba.baidu.com is level‑3. In practice, the term “primary domain” is often used to refer to the level‑1 domain that can be independently registered.