Mastering Single Sign-On: Cookie, Token, and CAS Approaches Explained

Same‑Domain Cookie/Session SSO

This design relies on a central authentication server that issues a session cookie (or token) after a user logs in. All applications that share the same top‑level domain (e.g., *.example.com) can read this cookie and request user information from the authentication server, enabling seamless navigation between services.

Advantages : Simple to implement; works well with legacy systems; requires minimal changes to front‑end and back‑end code.

Disadvantages : Depends on browser cookies; limited to same‑domain or sub‑domain scenarios; poor support for cross‑domain, cross‑organization, mobile clients, or third‑party SaaS.

Typical use cases : Integration of legacy internal portals, multiple web applications under a single top‑level domain.

Token‑Based Distributed SSO (JWT/OAuth2)

After successful authentication, the auth service issues an access token such as a JSON Web Token (JWT). Each downstream subsystem validates the token either by verifying its digital signature with a public key or by calling the auth server’s introspection endpoint. This model is commonly combined with OAuth 2.0 / OpenID Connect (OIDC) and is suitable for web, mobile, and API‑driven scenarios.

Advantages : Strong cross‑domain and cross‑platform support; stateless verification (or optional stateful session); fine‑grained authorization; mature ecosystem and tooling.

Disadvantages : Requires careful token lifecycle management, including refresh and revocation mechanisms.

Typical use cases : New cloud‑native applications, micro‑service architectures, third‑party SaaS integration, unified login for apps and web portals.

Central Authentication Service (CAS) SSO

CAS introduces a dedicated authentication server that issues short‑lived tickets. The two main artifacts are:

TGC (Ticket Granting Cookie) : Stored under the CAS domain; proves the user has an active CAS session.

ST (Service Ticket) : A temporary ticket passed to a business application via URL parameters.

Typical authentication flow:

User accesses an application without a local session and is redirected to the CAS login page.

After successful login, CAS creates a session, generates an ST, and redirects the user back to the application with the ST as a query parameter.

The application receives the ST and validates it by calling the CAS server’s validation endpoint.

Upon successful validation, the application establishes its own local session for the user.

Advantages : Strict protocol, high security because tickets are validated server‑side and are short‑lived.

Disadvantages : More complex integration; each application must implement a CAS client.