Understanding Cookie‑Based Single Sign‑On and CAS Authentication Flow

The author, a senior architect, starts by pointing out that cookie‑based single sign‑on (SSO) stores encrypted usernames and passwords in cookies, which leads to repeated credential transmission and cross‑domain limitations.

1. Review of Cookie‑Based SSO – The core principle is to encrypt credentials, store them in a cookie, and let a filter validate the user on each request. This approach suffers from security risks and inability to work across domains.

2. Unified Authentication Center – To solve the problems, a dedicated authentication service (e.g., http://passport.com) is introduced. Users are redirected to this central server for login, which stores the session on the server side and issues a special credential (ticket) back to the client.

The flow includes four steps: (1) user accesses a protected site and is redirected to the authentication center; (2) the user logs in at the center, which records the session; (3) the center returns a ticket and a CASTGC cookie; (4) the original site validates the ticket and grants access.

3. CAS (Central Authentication Server) Overview – The article presents the CAS architecture, showing a separate CAS server (e.g., cas.qiandu.com) and multiple client web applications that use CAS client filters. The key filter class is org.jasig.cas.client.authentication.AuthenticationFilter, which checks login status and redirects unauthenticated users.

4. Detailed CAS Login Process

4.1 First visit to www.qiandu.com – The request passes through AuthenticationFilter, which redirects to the CAS server (label 1). The CAS server presents a login page (label 4). After successful login, the server issues a Service Ticket (ST) and a CASTGC cookie, then redirects back to the original site (label 7).

4.2 Second visit – The client already has a valid session, so the filter allows access without redirection.

4.3 Accessing another domain ( mail.qiandu.com) – The browser presents the CASTGC cookie to the CAS server, which validates it, issues a new ST, and redirects the user back to the target site, completing the SSO across domains.

Throughout the process, the article emphasizes the roles of TGT (Ticket‑Granting Ticket), TGC (Ticket‑Granting Cookie), and ST (Service Ticket) in maintaining secure, single‑sign‑on behavior.

5. Summary – The CAS‑based SSO solution centralizes authentication, eliminates repeated credential transmission, and supports cross‑domain access, providing a more secure and maintainable approach for backend systems.