How Does Single Sign-On (SSO) Work? A Deep Dive into CAS Architecture
This article explains the core concepts of Single Sign‑On (SSO), detailing the roles of the CAS Server, CAS Client, and browser, and walks through the complete authentication flow with diagrams, illustrating how a single login grants access to multiple systems.
What Is Single Sign‑On (SSO)
Single Sign‑On (SSO) is an identity authentication mechanism that allows a user to log in once to a central system and then access multiple related applications without re‑entering credentials.
SSO is widely used in enterprise portals, cloud service integrations, mobile apps, and third‑party API access, enabling employees to access email, office suites, and internal systems through a single authentication step.
Core Components of a Typical SSO Implementation
CAS Server (Authentication Center)
The CAS Server (Central Authentication Service) is the heart of the SSO system. Its main responsibilities are:
User identity verification (login credential check).
Issuing tickets (e.g., TGT – Ticket‑Granting Ticket, ST – Service Ticket).
Managing the global SSO session.
It can be thought of as a “single login entry point + trust center”.
CAS Client (Application System)
CAS Clients are the individual business systems that integrate with SSO, such as user portals, order systems, or admin back‑ends.
Key responsibilities:
Intercept unauthenticated requests and redirect them to the CAS Server.
Browser (User Agent)
The browser acts as a bridge between the client and the server, handling redirects and storing authentication cookies (e.g., TGT).
Key responsibilities:
Perform request redirection.
Store cookies that carry authentication tokens.
Pass authentication information across different systems.
SSO Authentication Flow
The complete authentication process proceeds as follows:
User accesses a CAS Client (business system) via the browser.
Client detects that the user is not logged in and redirects the request to the CAS Server.
User completes login authentication on the CAS Server.
CAS Server generates a ticket (e.g., Service Ticket) and returns it to the browser.
Browser sends the ticket back to the original client.
Client validates the ticket with the CAS Server.
Upon successful validation, the client creates a local session and the login is completed.
Mike Chen's Internet Architecture
Over ten years of BAT architecture experience, shared generously!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.