How to Implement Cross-Domain Single Sign-On (SSO) with Cookies, Auth Centers, and LocalStorage

Introduction

In B/S systems, login is usually based on cookies. After a user logs in successfully, the login state is recorded in a Session or a Token, which must be stored on the client (Session ID or Token) and sent with every subsequent request.

Because cookies are the most convenient way to carry this information, the Session ID or Token is typically saved in a cookie, and the server validates the cookie to determine whether the user is logged in.

Single Sign‑On (SSO) means that a user logs in once and can access all trusted applications under the same account platform without re‑authenticating.

For example, Baidu Tieba and Baidu Maps are two different applications under Baidu; after logging in on Tieba, the user can access Maps without logging in again, which demonstrates SSO.

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

However, sharing a Session ID via cookie is limited by domain scope: a cookie set for app1.com is not automatically sent to app2.com. The key to SSO is making the Session ID (or Token) available across different domains.

Implementation 1: Parent‑Domain Cookie

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

By setting the cookie’s domain to the main domain (e.g., baidu.com) and path to /, every sub‑domain can access the same cookie, enabling SSO for applications that share the same primary domain.

This method is simple but does not work across different primary domains.

Implementation 2: Authentication Center

Deploy a dedicated authentication center—a separate web service that handles login requests.

Users log in to 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 can detect whether the user is already logged in via its own cookie.

If the user is not logged in, the center returns a login page; after successful login it generates a Token, appends it to the target URL, and redirects back to the application.

The application then validates the Token with the authentication center, records the user’s login state, writes its own cookie, and grants access. This approach is more complex but supports cross‑domain scenarios and offers good extensibility.

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 created by a Dazhong Dianping engineer; not recommended for production use.

Implementation 3: LocalStorage Cross‑Domain

Instead of using 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 multiple domains, the front‑end can create an invisible iframe that loads a page on the target domain and uses postMessage() to transfer the token, where the iframe’s page writes the token into its own LocalStorage.

Key code:

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

// Dynamically create an invisible iframe that loads a cross‑domain HTML
var iframe = document.createElement("iframe");
iframe.src = "http://app1.com/localstorage.html";
document.body.append(iframe);

// Use postMessage() to send the token to the iframe
setTimeout(function () {
    iframe.contentWindow.postMessage(token, "http://app1.com");
}, 4000);
setTimeout(function () {
    iframe.remove();
}, 6000);

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

The front‑end writes the same token into the LocalStorage of multiple domains via the iframe technique, and each request includes the token, achieving cross‑domain SSO with minimal back‑end involvement.

This method is fully controlled by the front‑end, works across domains, and requires little back‑end changes.

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. From a user perspective, the primary domain (e.g., baidu.com) is considered the first level, and its direct sub‑domains (e.g., tieba.baidu.com) are second‑level.

To avoid confusion, the article uses the term “primary domain” instead of “first‑level domain”.