Mastering Single Sign-On: Cookie, Auth Center, and LocalStorage Strategies

Introduction

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, and the client must keep the Session ID or Token and send it with every subsequent request.

Cookies are the most convenient way to store these identifiers, so the Session ID or Token is often saved in a cookie and validated by the server on each request.

Single Sign‑On (SSO) allows a user to log in once and access multiple trusted applications under the same account platform, e.g., logging into Baidu Tieba automatically grants access to Baidu Maps.

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

However, because browsers restrict cookie scope to a domain, a Session ID saved in a cookie cannot be sent to a different domain, which is the main challenge for 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 among sub‑domains.

By configuring the cookie’s domain to the main domain (e.g., baidu.com) and path to /, all sub‑domains can access the same cookie, enabling SSO.

This method is simple but only works when all applications share the same parent domain.

Implementation 2: Authentication Center

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

Users log in to the authentication center, which records the login state and writes a Token into its own cookie (not accessible by other applications). When an application receives a request without a Token, it redirects the user to the authentication center. After successful login, the center appends the Token to the target URL and redirects back.

The application then validates the Token with the authentication center, records the user’s state, writes the Token into its own cookie, and grants access.

Open‑source examples:

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

XXL‑SSO – a simple SSO system developed by a Dazhong Dianping engineer (not recommended for production).

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

Implementation 3: Cross‑Domain LocalStorage

Because modern browsers increasingly restrict cross‑domain cookie usage (e.g., SameSite attribute), an alternative is to store the Session ID or Token in localStorage on the client side.

The front‑end retrieves the Token from the authentication response and saves it to localStorage. It can then use an invisible iframe and postMessage to write the same Token into localStorage of other domains.

// Get token
var token = result.data.token;
// Create invisible iframe loading a cross‑domain HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);
// Send token to iframe via postMessage
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
window.addEventListener('message', function (event) {
    localStorage.setItem('token', event.data);
}, false);

The front‑end reads the Token from localStorage and includes it in each request to the back‑end, achieving token sharing across domains without server‑side involvement.

This method is fully controlled by the front‑end, requires minimal back‑end changes, and also supports cross‑domain scenarios.

Supplement: Domain Hierarchy

According to networking terminology, .com and .cn are top‑level domains, .com.cn or baidu.com are second‑level domains, and tieba.baidu.com is a third‑level domain. For clarity, the article uses “primary domain” to refer to the top‑level domain.