Three Practical Methods for Implementing Single Sign-On (SSO) in B/S Systems

In B/S systems, login is usually based on cookies: after a successful login the session ID or token is stored either in the server session or issued as a token, and the client keeps this information to include it in subsequent requests.

Because cookies are the most convenient way to carry authentication data, they are commonly used to store the session ID or token, and the server validates the cookie to determine whether the user is logged in.

Single Sign‑On (SSO) allows a user to log in once and then access multiple trusted applications under the same account platform without re‑authenticating.

For example, after logging into Baidu Tieba, a user can directly visit Baidu Maps without another login, which means the two services have implemented SSO.

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

However, sessions are usually stored in browser cookies, which are scoped to a specific domain, so a session cookie from app1.com will not be sent when the browser accesses app2.com . The key challenge of SSO is making the session ID or token available across different domains.

Implementation Method 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 setting the cookie’s domain to the main domain (e.g., baidu.com ) and path to / , every sub‑domain (e.g., tieba.baidu.com , map.baidu.com ) can read the same cookie, thus sharing the login state.

This method is simple but only works when all applications share the same primary domain; it does not support cross‑primary‑domain scenarios.

Implementation Method 2: Authentication Centre

An independent authentication centre handles all login requests. After a successful login it records the user’s state and writes a token into its own cookie (which is not directly accessible by other applications).

If an application receives a request without a token, it redirects the user to the authentication centre. The centre’s cookie is automatically sent with the redirect, allowing the centre to determine whether the user is already logged in.

When the centre confirms the user is logged in, it generates a token, appends it to the target URL, and redirects back to the original application.

The application then validates the token with the centre, records the login state locally, writes its own token cookie, and grants access. This approach is more complex but supports cross‑domain usage and offers good extensibility.

Two open‑source authentication centre examples are mentioned: Apereo CAS and XXL‑SSO.

Implementation Method 3: LocalStorage Cross‑Domain

Because modern browsers restrict cookie cross‑domain transmission (especially with the SameSite attribute), an alternative is to store the session ID or token in localStorage on the client side.

The front‑end can write the token into its own localStorage and, using an invisible iframe plus postMessage() , propagate the token to other domains that load a cooperating HTML page.

// 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 page, listen for the message and store token in localStorage
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 SSO without server‑side involvement and supporting cross‑domain scenarios.

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. For practical purposes, the “primary domain” refers to the highest level that can be independently registered (e.g., baidu.com ).