Mastering Single Sign-On: How CAS Simplifies User Authentication Across Systems

Single Sign-On

Single Sign-On (SSO), also known as Single Sign-On, is an identity verification and authorization mechanism that allows a user to access multiple different applications or systems after a single login.

Why Single Sign-On Is Needed

For example, Alibaba’s ecosystem includes Taobao, Tmall, and dozens of sub‑systems. A single user action may involve many of these systems.

If each sub‑system required its own authentication, users would be overwhelmed and the systems would suffer from duplicated authentication logic.

SSO solves this by enabling a user to log in once and then access all mutually trusted applications.

SSO System – CAS

One typical implementation is the CAS (Central Authentication Service) system, an open‑source project initiated by Yale University to provide a reliable SSO method for web applications.

CAS core components include: CAS Server, CAS Client, and Service.

1. CAS Server

The server handles user authentication and authorization, generating and managing tokens. When a user logs in for the first time, the server validates credentials, creates a token, and returns it to the application.

2. CAS Client

The client is integrated into applications, redirecting users to the CAS Server for login and, after successful authentication, validating the token with the server.

3. Service

A Service represents a protected application. Each Service has a unique identifier.

Implementation Principle

CAS provides a centralized authentication service. After a user logs in once, CAS issues a ticket (token) that can be used to access multiple associated applications without re‑entering credentials.

SSO Workflow

User accesses Application A: The application detects the user is not logged in and redirects to the CAS Server.

Redirect to CAS Server: Application A sends the user to the CAS login page.

CAS login: The user enters credentials; the CAS Server validates them and generates a ticket.

Ticket returned to Application A: Application A uses the ticket to request user information from the CAS Server.

Access other applications: When the user later accesses Application B, it redirects the user to the CAS Server.

Ticket returned to Application B: The CAS Server directly returns a ticket to Application B without requiring the user to re‑enter credentials.

Application B validates ticket: Application B sends the ticket to the CAS Server, which confirms its validity and returns user information.

Subsequent accesses: The user can continue to access other trusted applications without additional logins, as the CAS Server validates the ticket each time.

Common Application Scenarios

1. E‑commerce platforms – Provide seamless shopping across multiple brand sites.

2. Large enterprise intranet portals – Enable employees to access HR, finance, collaboration tools, etc., with a single login.

3. Educational institution portals – Allow students and staff to move between campus portals and online learning platforms.

4. Financial services – Let customers switch between online banking, investment management, and insurance services effortlessly.