Comprehensive Overview of Authentication, Authorization, and Access Control Methods

Before discussing authentication methods, the article defines Authentication (identifying a user), Authorization (granting permission), and Access/Permission Control (enforcing allowed actions), illustrating their relationships.

1. HTTP Basic Authentication uses the Authorization: Basic <Base64> header; the client sends a request, the server responds with 401 Unauthorized and a WWW-Authenticate: Basic realm="..." challenge, after which the client resends credentials encoded in Base64.

2. Session‑Cookie Authentication relies on a server‑side Session stored in memory, Redis, etc., with the client receiving a Set‑Cookie containing a session_id . Subsequent requests include the cookie, allowing the server to retrieve session data.

3. Token Authentication issues a short‑lived Access Token and a longer‑lived Refresh Token . The client stores the token (e.g., in localStorage) and sends it via the Authorization: Bearer <token> header; the server validates the token without maintaining session state.

4. JWT (JSON Web Token) consists of three Base64URL parts: Header (algorithm and type), Payload (claims such as iss , exp , sub ), and Signature (HMAC or RSA). JWT enables stateless authentication by embedding user claims directly in the token.

5. Single Sign‑On (SSO) allows a user to log in once and access multiple trusted applications. The article explains same‑domain SSO using shared cookies and cross‑domain SSO using the CAS (Central Authentication Service) protocol, which issues a Ticket Granting Cookie (TGC) and service tickets ( ST ) for each application.

6. OAuth 2.0 provides four grant types: Authorization Code, Implicit, Password Credentials, and Client Credentials. Each flow is described with request URLs, required parameters ( client_id , redirect_uri , response_type , etc.), and token exchange steps.

7. Unique Login enforces a single active session per user by generating a new token on each login and invalidating previous tokens, ensuring that a login from a new device forces the old device to re‑authenticate.

8. QR‑Code (Scan) Login involves three parties (PC, mobile, server). The PC requests a QR code ID, the mobile app scans it, the server links the mobile token to the QR ID, and the PC polls for login status before receiving a final token.

9. One‑Click Login for Native Apps leverages mobile carrier SDKs to obtain the device’s phone number directly (after user consent), eliminating SMS verification. The SDK returns a temporary token which the server exchanges for the actual phone number, then creates or logs in the user.

The article concludes with a comparison table recommending appropriate authentication mechanisms for different scenarios, such as internal networks, large web platforms, mobile apps, and cross‑domain ecosystems.