10 Common Authentication Techniques Explained: From Basic Auth to OAuth and QR‑Login

Fundamental Concepts

Identification (Authentication)

Authentication verifies a claimant’s identity using credentials such as username/password, biometric data, or one‑time codes.

Authorization

Authorization delegates specific resource‑access rights from a resource owner to a requester (e.g., bank cards, door‑access cards).

Authentication (Access Control)

Authentication confirms that the claimed identity is genuine and produces a permission set for subsequent access‑control checks.

Access Control

Access control defines a list of permissible operations and enforces allow/deny decisions for each request.

1. HTTP Basic Authentication

Basic Access Authentication sends a username and password encoded in Base64 with each HTTP request.

Workflow Diagram

Steps

Client requests a protected resource.

Server responds with 401 Unauthorized and WWW-Authenticate: Basic realm="example.com".

Client prompts the user for credentials, encodes them with Base64, and resends the request.

Server validates the Authorization header and returns the resource if the credentials are valid.

Pros

Simple and supported by all major browsers.

Cons

Credentials travel in clear text (Base64 is reversible) – vulnerable to eavesdropping and replay attacks.

No programmatic logout; browsers clear credentials only when the tab or history is cleared.

Typical Use

Internal networks or low‑security environments.

2. Session‑Cookie Authentication

Combines a server‑side Session identifier with a client‑side Cookie to maintain state across HTTP requests.

Cookie Basics

Stored on the client, can be tampered with, limited to 4 KB.

Not shared across top‑level domains; subdomains can share via the Domain attribute.

Session Basics

Stored on the server (memory, DB, file, or Redis cluster).

Provides higher security because the client never sees the actual session data.

Workflow Diagram

Steps

Client submits login credentials.

Server validates them, creates a Session, generates a unique sid, and sends Set‑Cookie: sid=… to the client.

Client stores the sid in a cookie; subsequent requests automatically include it.

Server extracts the sid, looks up the session, and decides whether the request is authorized.

Pros

Simple to use.

Server‑side session data can be managed (e.g., logout by deleting the session).

No client‑side code required.

Cons

Relies on cookies; disabled cookies break the flow.

Cookies are vulnerable to CSRF attacks.

Server memory consumption grows with the number of active sessions.

Mobile support is limited.

Popular Front‑End Libraries

express-session

– GitHub: https://github.com/expressjs/session koa-session – GitHub: https://github.com/koajs/session

3. Token Authentication

A token is a credential issued after successful login; the client presents it on subsequent API calls.

Token Structure

uid

(user ID) + time (timestamp) + sign (hash signature).

Workflow Diagram

Steps

Client sends username/password to the server.

Server validates credentials and issues a token.

Client stores the token (e.g., localStorage or cookie).

Client includes the token in the Authorization: Bearer <token> header for protected API calls.

Server validates the token; if valid, returns data; otherwise returns 401.

Pros

Stateless on the server – no session storage needed.

Works well for mobile apps and cross‑origin requests.

Mitigates CSRF because the token is not automatically sent by the browser.

Supports API‑centric architectures.

Cons

Requires front‑end and back‑end coordination.

Token size is larger than a simple sid, consuming more bandwidth.

Verification adds cryptographic overhead.

Short lifetimes demand a refresh mechanism.

Refresh Token

Access tokens are short‑lived; a Refresh Token can be used to obtain a new access token without re‑entering credentials.

Refresh Token Flow Diagram

4. JWT (JSON Web Token)

JWT encodes a JSON payload and signs it, enabling stateless authentication.

Structure

Three Base64URL‑encoded parts separated by dots: Header. Payload. Signature.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header

{"alg":"HS256","typ":"JWT"}

Payload (Claims)

iss

– issuer exp – expiration time sub – subject aud – audience nbf – not before iat – issued at jti – JWT ID

Custom claims (e.g., {"sub":"1234567890","name":"John Doe","admin":true}) can be added.

Signature

Generated with a secret key using the algorithm specified in the header (e.g., HMAC‑SHA256):

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Usage

After login, the server returns a JWT that the client stores (cookie or localStorage) and sends in the Authorization: Bearer <token> header on each request.

Pros

No server‑side session storage – fits RESTful APIs.

Payload can carry user data, reducing database lookups.

Cons

JWTs are not encrypted by default; they can be read if intercepted.

Because the server does not store state, revoking a token before expiration requires additional infrastructure.

Popular Front‑End Libraries

express-jwt

– GitHub: https://github.com/auth0/express-jwt koa-jwt – GitHub: https://github.com/koajs/jwt

5. Single Sign‑On (SSO)

Same‑Domain SSO

When sub‑systems share the same primary domain (e.g., tieba.baidu.com and pan.baidu.com), the login server sets a cookie with Domain=.baidu.com. All sub‑domains automatically receive the cookie, achieving seamless login.

Cross‑Domain SSO (CAS)

Central Authentication Service (CAS) enables SSO across different primary domains.

CAS Endpoints

/login

– login page. /logout – logout. /validate – check login status. /serviceValidate – service‑side ticket validation.

Ticket Types

TGT (Ticket‑Granting Ticket) – stored in the CAS session.

TGC (Ticket‑Granting Cookie) – browser cookie that references the TGT.

ST (Service Ticket) – issued for a specific application after the user is authenticated.

CAS Flow Diagram

6. OAuth 2.0

OAuth 2.0 is an open standard that lets users authorize third‑party applications to access their data without sharing passwords.

Grant Types

Authorization Code – best for web apps with a back‑end. The client obtains an authorization code, then exchanges it for an access token using client_id and client_secret.

Implicit – for pure front‑end apps; the token is returned directly in the URL fragment.

Password Credentials – the client collects the user’s username/password and sends them to the token endpoint (requires high trust).

Client Credentials – the client authenticates itself (no user) to obtain a token, suitable for CLI tools.

Authorization Code Flow

Client redirects the user to the authorization server, e.g.,

https://auth.example.com/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

.

User logs in and consents; the server redirects back with code=AUTHORIZATION_CODE.

Client’s back‑end exchanges the code for a token via a POST request to https://auth.example.com/oauth/token with client_id, client_secret, grant_type=authorization_code, code, and redirect_uri.

Authorization server returns JSON containing access_token, refresh_token, expires_in, etc.

Implicit Flow

Client redirects the user with response_type=token.

After login, the server redirects back with #access_token=… in the fragment.

Password Credentials Flow

Client sends grant_type=password, username, password, client_id (and optionally client_secret) to the token endpoint.

Authorization server validates and returns an access token.

Client Credentials Flow

Client sends grant_type=client_credentials, client_id, and client_secret to the token endpoint.

Authorization server returns an access token representing the client itself.

7. Federated and Trusted Login

Federated login uses third‑party credentials (e.g., QQ, WeChat) to authenticate users on another site. Trusted login refers to scenarios where the user does not need to interact (e.g., device‑bound login).

8. Unique (Single‑Device) Login

Ensures that a user can be logged in on only one device at a time. When a second device logs in, the first device’s token becomes invalid, forcing re‑authentication.

Flow

Device A logs in → server issues a token and records the session.

Device B logs in → server detects an existing session, invalidates the previous token, and issues a new one.

9. QR‑Code Login

Diagram

Steps

PC requests a QR code; server creates a UUID and stores it with the PC’s device info in Redis.

PC displays the QR code and polls the server for status.

User scans the code with a logged‑in mobile app; the app sends its token and the UUID to the server.

Server links the mobile token to the UUID, generates a temporary token for confirmation.

User confirms on the mobile app; server validates the temporary token, marks the QR code as logged‑in, and issues a final token for the PC.

PC receives the final token and completes the login.

10. One‑Click Mobile Login

Workflow

App initializes the carrier SDK with AppKey and AppSecret.

SDK opens an authorization page showing a masked phone number and carrier agreements.

User consents; SDK returns a temporary token.

App sends the token to its back‑end; the back‑end calls the carrier’s API to retrieve the real phone number.

Back‑end creates or logs in the user using the phone number and returns a session token to the app.

Carrier SDKs

China Mobile – Internet Capability Open Platform

China Telecom – Tianyi Account Open Platform

China Unicom – WO+ Open Platform

Third‑party providers (Alibaba, Chuanglan, Jiguang, mob) also offer unified number‑verification services.

Conclusion

The ten authentication methods can be chosen based on security requirements, system size, and client type:

HTTP Basic Auth – simple, low‑security internal networks.

Session‑Cookie – typical for medium‑large web sites (excluding native apps).

Token & JWT – suitable for most enterprise applications; JWT offers better performance and statelessness.

SSO – ideal for large enterprises with many subsystems.

OAuth 2.0 – best for services that need quick user registration via third‑party accounts.

QR‑Code Login – fits three‑party (PC, mobile, server) deployments.

One‑Click Login – optimized for native mobile apps.