How SSO Works: From CAS Architecture to Real‑World Implementation

Background of SSO Systems

In a single‑web‑app scenario, authentication is simple: after a successful login the server writes a cookie and each request carries that cookie, which the server validates to determine login status. As business grows and multiple systems need to cooperate, maintaining separate authentication logic for each system leads to redundancy and incompatibility.

Each system must maintain its own authentication logic, causing duplication.

When crossing systems, authentication information may become invalid, requiring compatibility handling.

Therefore a common authentication module—an SSO system—is abstracted to provide a unified login service for all business systems.

Typical SSO System Model

The SSO system consists of two main parts: a global session managed by the SSO server and a local session managed by the SSO client embedded in each business application. The client creates, deletes, and validates the local session, while the server maintains the global session.

CAS Framework Overview

CAS is a classic open‑source SSO framework that many systems borrow from. It supports multiple client languages (Go, Python, PHP, Java, .NET) and its server side is built with Spring MVC + Spring Web Flow, using ticket, authentication components, and storage back‑ends such as LDAP, databases, or Active Directory. Typical storage combines a relational database with Redis or Memcached.

Authentication Flow

The authentication process can be divided into three cases:

1. First access to a protected resource

The user is redirected to the SSO server login page, submits credentials, the server validates them, issues a ticket, and redirects back to the client. The client validates the ticket, creates a local session cookie, and redirects the user to the original resource.

Key client code:

final Assertion assertion = session != null ? (Assertion) session.getAttribute(CONST_CAS_ASSERTION) : null;
if (assertion != null) {
    filterChain.doFilter(request, response);
    return;
}
final String serviceUrl = constructServiceUrl(request, response);
final String ticket = CommonUtils.safeGetParameter(request,getArtifactParameterName());
final boolean wasGatewayed = this.gatewayStorage.hasGatewayedAlready(request, serviceUrl);
if (CommonUtils.isNotBlank(ticket) || wasGatewayed) {
    filterChain.doFilter(request, response);
    return;
}

If login succeeds, the client redirects directly:

response.sendRedirect(urlToRedirectTo);

2. Subsequent access to the same system

The browser already holds the local session cookie, so the request passes the filter without redirection.

3. First access to a different system

No local session exists for the new domain, so the request is redirected to the SSO server. Because the user is already logged in globally, the server issues a ticket, the client validates it, creates a new local session cookie, and redirects back to the original resource.

Taobao SSO Architecture and Implementation

Taobao’s SSO adds a synchronization module to the login status, making the e‑commerce platform more flexible.

Step 1: Synchronize login status

The SSO client filter intercepts static page requests. If the local session cookie is missing or invalid while the global session is valid, the filter redirects to login.taobao.jump, which always redirects back to the client with a token and the original URL. Only one redirection occurs.

Step 2: Validate login status

When a protected resource is requested, the filter checks the login status. If the request is a synchronous navigation and the user is not logged in, it redirects to the login page. For asynchronous Ajax requests, it returns the login status, redirecturl, and loginurl for client‑side handling.

Step 3: Verify ticket

After successful SSO server login, the client receives a token, validates it with the SSO server, and, if valid, returns user information and cookies issued by the SSO server.