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

Preface

In B/S systems the login function is usually based on cookies; after a successful login the session state is stored in a Session or a Token, and the client keeps the Session ID or Token (often in a cookie) and sends it with every subsequent request.

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. Sharing Session objects via Redis works only for applications under the same domain, because cookies are scoped by domain and cannot be sent across different top‑level domains.

Implementation 1: Parent‑Domain Cookie

Cookie scope is determined by the domain and path attributes. Setting domain to a parent domain (e.g., baidu.com ) makes the cookie shared by all sub‑domains.

By storing the Session ID or Token in a cookie whose domain is the parent domain and path is / , all sub‑domains can read the same cookie, enabling SSO as long as the applications share a common parent domain.

Summary: This method is simple but does not support cross‑parent‑domain scenarios.

Implementation 2: Authentication Center

Deploy an independent authentication center that handles login requests. After a successful login the center records the user’s state and writes a Token into its own cookie.

The client is redirected to the authentication center when a protected application does not have a Token. The center checks its cookie, issues a Token, appends it to the target URL, and returns it to the application.

The application then validates the Token with the authentication center, records the login state, writes its own cookie, and grants access. Subsequent requests carry the application‑specific cookie.

Open‑source examples:

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

XXL‑SSO – a lightweight SSO system by a Meituan‑Dianping engineer (not recommended for production).

Summary: This approach is more complex, supports cross‑domain SSO, and offers good extensibility; it is the standard practice.

Implementation 3: LocalStorage Cross‑Domain

Instead of cookies, store the Session ID or Token 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 .

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

// Create invisible iframe loading a cross‑domain page
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);

// Send token to iframe via postMessage after a short delay
setTimeout(function () {
    iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);

// Remove iframe after use
setTimeout(function () {
    iframe.remove();
}, 6000);

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

The front‑end then reads the token from localStorage before each request, achieving token sharing across domains with minimal back‑end involvement.

Summary: This method is fully controlled by the front‑end, requires almost no back‑end changes, and also supports cross‑domain SSO.

Supplement: Domain Hierarchy

According to networking terminology, .com and .cn are top‑level domains, baidu.com is a second‑level domain, and tieba.baidu.com is a third‑level domain. In practice, the term “primary domain” is often used for a domain that can be independently registered (e.g., baidu.com ), while its direct sub‑domains (e.g., tieba.baidu.com ) are considered secondary domains.