Mastering Authentication: From Basic Login to SSO, OAuth, JWT, and HMAC

Authentication Overview

Authentication is the first gate to a system, requiring users to present proof of identity. Many systems lack proper authentication or rely only on simple username/password, which does not meet security standards.

Authentication Types

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

1. UI Login Authentication

Users access the system via front‑end (browser or mobile). After successful login, a session is created, often using cookies. Common solutions include SSO, LDAP, OAuth, Basic, and Kerberos.

1.1 Basic

Simple username/password stored in a database (plain or encrypted). After verification, the server generates a session.

1.2 LDAP

Lightweight Directory Access Protocol, a directory database optimized for read‑heavy queries, organized in a tree structure.

1.3 OAuth

OAuth 2.0 is an industry‑standard authorization protocol that issues time‑limited tokens for third‑party applications, commonly used for social logins.

1.4 Kerberos

A network authentication framework that uses a Key Distribution Center (KDC) to provide strong authentication, often used for single sign‑on in Hadoop clusters.

1.5 SSO

Single Sign‑On allows users to log in once and access multiple systems without re‑entering credentials. The most common implementation is CAS, which can be combined with LDAP.

2. API Call Authentication

Clients call system APIs directly. Common schemes include HMAC, JWT, and certificates.

2.1 HMAC

Hash‑based Message Authentication Code uses an AccessKey and SecretKey. The client creates a string of request parameters, hashes it with the SecretKey, and sends the hash and AccessKey. The server recomputes the hash to verify integrity.

2.2 JWT

JSON Web Token stores user information on the client side. The server issues a token consisting of Header, Payload, and Signature. Subsequent requests include the token, allowing stateless authentication.

Designing UI Login Authentication

In micro‑service architectures, the authentication component can run as a module or a separate service, typically placed behind an API gateway.

The flow is:

User accesses the front‑end service, which forwards the request to the API gateway.

The gateway forwards to the authentication service, which checks the token; if invalid, the request is redirected to the CAS server.

After successful login, CAS returns a token and redirects back to the front‑end.

The front‑end includes the token in subsequent requests; the authentication service validates it and forwards the request to back‑end services.

Key Design Points

Cross‑Domain Access : Tokens must be sent in headers or request bodies, not cookies, and CORS headers (Access‑Control‑Allow‑Origin) must be configured.

Cache : To reduce repeated validation, the gateway can cache validated session information.

CAS Client : Handles redirection to the CAS server, token verification, session creation, and cookie management.

Designing API Call Authentication

A typical token‑based design issues a long string token per user, which maps to multiple micro‑service endpoints and expires after a set period.

User obtains a token via a login API.

Subsequent API calls include the token for authentication.

Why SSO Is Needed

Multiple independent applications lead to credential sprawl, reducing efficiency and increasing the risk of forgotten passwords. SSO, especially using CAS, solves this by allowing a single authentication to grant access across systems.

CAS Overview

CAS (Central Authentication Service) provides a reliable SSO solution. It consists of a CAS Server (central authentication) and CAS Clients integrated into each application.

Key CAS Terminology

ST (Service Ticket) : Generated by the TGT, used to access a specific service.

TGC (Ticket‑Granting Cookie) : Cookie that identifies the user session.

TGT (Ticket‑Granting Ticket) : Grants the ability to obtain service tickets.

Session : Application‑specific session created after ST validation.

User Login Flow

User accesses a protected resource; the system redirects to CAS if no ST is present.

CAS prompts for credentials, issues TGT and TGC, and redirects back with an ST.

The application validates the ST with CAS, creates a session, and serves the resource.

User Logout Flow

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

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

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

Implementing CAS requires custom client code for different frameworks (e.g., Django, Tornado), but a unified micro‑service‑based SSO solution can simplify this across the organization.