How Single Sign-On (SSO) Works: Architecture and Flow Explained
This article explains the fundamentals of Single Sign-On (SSO), detailing its cross‑system authentication mechanism, core components such as CAS Server, CAS Client, and User Agent, and walks through the step‑by‑step flow that enables users to log in once and access multiple trusted applications seamlessly.
Single Sign-On (SSO) is a fundamental capability in large‑scale architectures, allowing users to log in once and seamlessly access multiple trusted applications without re‑entering credentials.
The essence of SSO is cross‑system sharing of authentication information, with the core focus on trustworthy transmission and verification of login credentials.
SSO Architecture
The overall architecture consists of three core components:
CAS Server (Authentication Center/IdP) : the sole authentication server responsible for user verification, generating and managing Ticket‑Granting Tickets (TGT) and Service Tickets (ST), and providing a unified login page.
CAS Client (SP) : integrated into each application system, it intercepts unauthenticated requests, redirects users to the CAS Server, validates the returned ST, and establishes a local session.
User Agent : the user's browser, which initiates requests, carries the TGT cookie, and follows redirects.
The interaction flow is illustrated below:
[Browser] --> Request Business System A
|
v
[Business System A] -- not logged in --> redirect to CAS Server login page
|
v
User enters credentials --> CAS Server validates --> generates TGT (cookie) and ST
|
v
[Browser] <-- ST <-- CAS Server
|
v
[Business System A] validates ST with CAS Server --> creates local session, login successful
|
v
User accesses other systems --> uses existing TGT to obtain new ST without re‑loginThe step‑by‑step process is:
User accesses Business System A; the system detects no login and redirects to the CAS authentication center with the target URL.
User logs in at the CAS center; CAS generates a TGT (stored as a cookie) and an ST (service ticket).
CAS redirects back to Business System A with the ST.
Business System A validates the ST with CAS; upon success, it establishes a local login state.
When the user accesses other systems, the existing TGT allows issuance of new STs without additional login, achieving a seamless single‑sign‑on experience.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
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.
