How Single Sign-On (SSO) Works: Architecture, Components, and Flow Explained
This article explains the fundamentals of Single Sign-On (SSO), describing its purpose of simplifying user authentication across multiple services, the core components such as CAS Server, CAS Client, and the browser, and walks through the step‑by‑step authentication flow with illustrative diagrams.
Single Sign-On (SSO) provides users with a unified authentication experience across multiple applications or services, allowing one login to grant access to all authorized resources.
The main goals of SSO are to improve user experience, reduce repeated credential entry, and centralize identity and permission management, which is especially valuable in enterprise environments, cloud services, and large internet platforms.
Core Components
The SSO architecture relies on an independent authentication center, often referred to as a CAS (Central Authentication Service) or SSO server, and the following participants:
CAS Server : Acts as the central authority that validates user credentials, creates tickets or tokens, and manages sessions.
CAS Client : Deployed within each protected application, it redirects unauthenticated users to the CAS Server, validates returned tickets, and establishes local sessions.
User Browser : Carries authentication information (tickets or cookies) and handles redirects between the client application and the CAS Server.
CAS Server Details
The CAS Server provides a unified login page, verifies credentials (e.g., username/password, two‑factor authentication), and upon successful verification issues a ticket or token that represents the authenticated session.
CAS Client Details
When a protected resource receives an unauthenticated request, the CAS Client redirects the user’s browser to the CAS Server, including a service parameter that indicates the callback URL. After the user logs in, the CAS Server redirects back with a Service Ticket (ST) that the client validates before granting access.
User Browser Role
The browser follows redirects between the client and the CAS Server, carrying the Service Ticket or session cookie, enabling the seamless handoff of authentication state.
SSO Authentication Flow
The complete flow proceeds as follows:
User accesses a protected application (CAS Client).
CAS Client redirects the browser to the CAS Server, attaching the service parameter.
CAS Server authenticates the user (e.g., username/password, 2FA).
Upon success, the CAS Server issues a Service Ticket (ST) and redirects the browser back to the original application.
CAS Client receives the ST, validates it with the CAS Server, creates a local session, and grants access to the protected resource.
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.