Three Single Sign-On Mechanisms and Their Implementation Methods

Introduction

This article explains three mechanisms of Single Sign‑On (SSO): the stateless HTTP protocol, the session mechanism, and the login‑state mechanism. It then presents three concrete implementation approaches: a parent‑domain cookie, an authentication centre, and a LocalStorage cross‑domain solution, each illustrated with diagrams and code snippets.

Stateless HTTP Protocol

Web applications follow a browser/server architecture where HTTP, a stateless protocol, handles communication. Each request is processed independently, as shown in the diagram below.

Session Mechanism

When a browser first accesses the server, the server creates a session and returns a session ID to the browser. The browser stores this ID (commonly in a cookie) and includes it in subsequent requests, allowing the server to recognize the same user.

The session ID can be transmitted either as a request parameter or via a cookie. In Tomcat, the cookie named JSESSIONID carries the session ID, as illustrated below.

Login State

After a user logs in, the server marks the associated session as authorized. The following Java code shows how to set and check this flag.

HttpSession session = request.getSession();<br/>session.setAttribute("isLogin", true);

Later requests can verify the login status with:

HttpSession session = request.getSession();<br/>session.getAttribute("isLogin");

Only sessions with isLogin=true are allowed to access protected resources.

Implementation Method 1: Parent‑Domain Cookie

By setting the cookie’s domain attribute to a common parent domain (e.g., baidu.com) and the path to /, all sub‑domains share the same cookie, enabling SSO across them.

Implementation Method 2: Authentication Centre

A dedicated authentication centre handles login once, stores a token in a cookie, and redirects users back to the target application with the token appended to the URL. The target application validates the token (e.g., via Apereo CAS or XXL‑SSO) before granting access.

Implementation Method 3: LocalStorage Cross‑Domain

When cookies cannot be shared across domains, the token can be stored in localStorage and propagated to other domains using an invisible iframe and the postMessage API. The following JavaScript demonstrates this technique.

// Get token from login response<br/>var token = result.data.token;<br/><br/>// Create hidden iframe that loads a cross‑domain page<br/>var iframe = document.createElement("iframe");<br/>iframe.src = "http://app1.com/localstorage.html";<br/>document.body.append(iframe);<br/><br/>// Send token to iframe via postMessage<br/>setTimeout(function () {<br/>    iframe.contentWindow.postMessage(token, "http://app1.com");<br/>}, 4000);<br/><br/>// Clean up iframe after use<br/>setTimeout(function () {<br/>    iframe.remove();<br/>}, 6000);<br/><br/>// In the iframe page, listen for the message and store token in localStorage<br/>window.addEventListener('message', function (event) {<br/>    localStorage.setItem('token', event.data);<br/>}, false);

Before each request to a protected backend, the frontend reads the token from localStorage and includes it in the request, achieving SSO without relying on cookies.