Comprehensive Guide to Authentication: Types, Protocols, and Design for Web and API Services

1. Introduction to Authentication Authentication is the first security gate for any system, requiring users to prove their identity. Many systems lack proper authentication or rely only on simple username/password, which does not meet security standards.

2. Classification of Authentication Authentication can be divided into two scenarios: UI login authentication and API call authentication, each using different methods.

2.1 UI Login Authentication Users access the system via front‑end (browser or mobile). After a successful login, a session is generated on the server and a cookie on the client. Common solutions include SSO, LDAP, OAuth, Basic, and Kerberos.

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

2.1.2 LDAP Lightweight Directory Access Protocol, a directory database optimized for read‑heavy queries, organized in a tree structure, often used for user lookup.

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

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

2.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.2 API Call Authentication Users call RESTful APIs directly. Common schemes include HMAC, JWT, and certificates.

2.2.1 HMAC Hash‑based Message Authentication Code uses a secret key and a hash algorithm (e.g., HMAC‑SHA256) to protect request integrity. It prevents tampering but does not hide the payload; transport encryption (HTTPS/SSL) is still required.

2.2.2 JWT JSON Web Token contains a Header, Payload, and Signature. The server issues a token after verifying credentials; subsequent requests carry the token, allowing stateless authentication.

3. Designing UI Login Authentication In micro‑service architectures, the front‑end service forwards requests to an API gateway, which then calls the authentication service. The gateway validates tokens, redirects to a CAS server if needed, and caches session information to improve performance. Key design points include cross‑domain token transmission (using headers instead of cookies) and caching validated sessions.

4. Designing API Call Authentication A typical design issues a long‑lived token per user, which maps to multiple micro‑service endpoints and expires after a set period. Clients obtain the token via a login API and include it in subsequent calls.

5. Why SSO Is Needed Without SSO, users must remember separate credentials for each application, leading to inefficiency and security risks. SSO, especially CAS, provides a centralized authentication service that issues tickets (ST, TGT, TGC) to enable seamless access across systems.

6. CAS Overview and Terminology CAS consists of a CAS Server (central authentication) and CAS Clients (integrated into each application). Important terms: Service Ticket (ST), Ticket‑Granting Cookie (TGC), Ticket‑Granting Ticket (TGT), and Session.

7. User Login Flow with CAS The flow includes initial access, redirection to CAS for authentication, issuance of TGC/TGT, generation of ST, and subsequent validation by target systems, enabling single sign‑on across multiple applications.

8. User Logout Flow The logout process clears local sessions and cookies, redirects to the CAS logout endpoint, which invalidates the TGT/TGC, and finally returns the user to the original system’s login page.

9. Additional Notes Redirection differs from forwarding; CAS provides three external interfaces (login, authentication, logout). Implementations vary across frameworks (e.g., Django, Tornado), requiring custom CAS client modules.