Comprehensive Guide to Authentication: UI Login, API Call Verification, SSO, and CAS

Authentication is the first security gate for any system, and many applications lack proper mechanisms beyond simple username/password checks.

Authentication Classification

Two main scenarios are considered: UI login verification and API call verification, each using different methods.

1. UI Login Verification

Typical solutions include:

Basic : Plain username/password stored in a database, generating a session upon successful validation.

LDAP : Lightweight Directory Access Protocol, a directory‑style database optimized for read‑heavy queries.

OAuth 2.0 : Industry‑standard authorization protocol that issues time‑limited tokens for third‑party access.

Kerberos : Network authentication framework using a Key Distribution Center for strong mutual authentication.

SSO (Single Sign‑On) : Allows users to log in once and access multiple systems without re‑authenticating; commonly implemented with CAS.

2. API Call Verification

Common schemes include:

HMAC : Hash‑based Message Authentication Code that uses an AccessKey and SecretKey to sign request parameters, ensuring integrity during transmission.

JWT : JSON Web Token carries user claims and expiration information; the server validates the token signature on each request.

Design of UI Login Authentication

In micro‑service environments, the authentication component can run as a module or a dedicated service. The flow typically involves the front‑end forwarding requests to an API gateway, which then delegates authentication to a dedicated service that may redirect to a CAS server for ticket validation.

Key Design Points

Cross‑Domain Access : Tokens should be placed in request headers or POST bodies because cookies cannot be shared across domains; CORS headers (Access‑Control‑Allow‑Origin=*) are required.

Cache : To reduce latency, the API gateway can cache validated session information, falling back to the authentication service when a token is missing.

CAS Client : Handles redirection to the CAS server, ticket acquisition, local session creation, and cookie management.

Design of API Call Authentication

Tokens are generated per user and linked to multiple micro‑service endpoints, with expiration and renewal mechanisms.

Why SSO is Needed

As enterprises grow, users face credential fatigue across many systems. SSO, especially using CAS, eliminates repeated logins and improves efficiency.

CAS Overview

CAS provides a central authentication service with components such as Service Ticket (ST), Ticket‑Granting Cookie (TGC), and Ticket‑Granting Ticket (TGT). It works alongside LDAP for directory storage.

User Login Flow (System A)

User accesses a protected resource; the system redirects to CAS for authentication.

After successful login, CAS issues a TGC and redirects back with an ST.

The system validates the ST, creates a local session, and serves the resource.

User Login Flow (System B)

Browser accesses another system; CAS provides an ST using the existing TGT.

The system validates the ST and creates its own session.

User Logout Flow

User initiates logout; the application clears its session and cookies.

The request is redirected to CAS, which clears the TGC/TGT.

CAS redirects back to the application, which now shows the login page.

Notes

Redirection involves two HTTP requests; forwarding is a single internal request.

CAS exposes three main endpoints: login, ticket validation, and logout.

Implementations differ across frameworks (e.g., Django, Tornado), so a unified micro‑service solution is recommended.