A Comprehensive Guide to Front‑End and Back‑End Authentication Strategies

Fundamental Concepts

Authentication (Identification) verifies a claimant’s identity, e.g., using an ID card or username/password.

Authorization delegates specific resource permissions from the resource owner to the executor.

Authentication (in security) validates that the identity claimed during authorization is genuine. The typical flow is authorize → authenticate → permission control .

Permission Control defines a list of allowed operations and checks whether a request is permitted.

1. HTTP Basic Authentication

Clients send a username and password encoded in Base64 in the Authorization: Basic <token> header. The server responds with 401 Unauthorized and a WWW-Authenticate: Basic realm="example.com" header when credentials are missing.

Advantages: simple, supported by all browsers.

Disadvantages: credentials travel in clear text (Base64 is reversible), vulnerable to replay attacks, and browsers cannot explicitly log out without closing the tab or clearing history.

Typical request:

GET /list/ HTTP/1.1
Host: www.example.com
Authorization: Basic aHR0cHdhdGNoOmY=

Typical response after successful validation:

HTTP/1.1 200 OK
...

2. Session‑Cookie Authentication

The server creates a Session object (stored in memory, Redis, DB, etc.) and returns a Set‑Cookie: sid=xxxx; Domain=.example.com header. The browser automatically includes the cookie in subsequent requests.

Cookie characteristics: client‑side storage, easy to tamper, size limit ~4 KB, up to ~20 cookies per domain, not shared across top‑level domains.

Session characteristics: stored server‑side, more secure, can hold any data type, but adds server memory overhead.

Comparison:

Security : Session is safer because the client cannot forge the server‑side data.

Data type : Cookie only stores strings; Session can store objects.

Expiration : Cookie can be long‑lived; Session usually expires quickly.

Common Node.js libraries:

express-session

koa-session

3. Token Authentication

After a successful login, the server issues a token (usually a random string containing uid, timestamp, and a sign hash). The client stores it in localStorage or a cookie and sends it in the Authorization header for subsequent API calls.

Client sends username/password to login endpoint.

Server validates credentials and returns a token.

Client stores the token.

Client includes the token in Authorization: Bearer <token> for protected resources.

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

Pros: stateless server, good scalability, works for mobile apps, prevents CSRF.

Cons: larger payload than a session ID, requires signing/encryption (performance cost), short expiration necessitates a refresh token.

Refresh Token

Two‑token model: Access Token (short‑lived) and Refresh Token (long‑lived). When the access token expires, the client exchanges the refresh token for a new access token.

4. JWT (JSON Web Token)

JWT is a compact, URL‑safe token consisting of three Base64URL‑encoded parts: Header, Payload, and Signature.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0...SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header includes alg (e.g., HS256) and typ (JWT).

Payload carries claims such as iss, sub, exp, etc., plus any custom fields.

Signature is computed as

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

to prevent tampering.

Pros: no server‑side state, reduces DB lookups, can embed user info.

Cons: cannot be revoked before expiration without additional blacklist logic; payload is only base64‑encoded (not encrypted) unless using JWE.

Node.js libraries:

express-jwt

koa-jwt

5. Single Sign‑On (SSO)

SSO allows a user to authenticate once and gain access to multiple trusted applications.

Same‑domain SSO

When two sub‑systems share the same top‑level domain (e.g., tieba.baidu.com and pan.baidu.com), the login server sets a cookie with Domain=.baidu.com. All sub‑domains automatically send this cookie, enabling seamless login.

Cross‑domain SSO (CAS)

CAS (Central Authentication Service) workflow:

Client accesses System A → redirected to CAS login page.

CAS prompts for credentials; upon success, it creates a TGC (Ticket‑Granting Cookie) and a Service Ticket ( ST), then redirects back to System A with ST as a query parameter.

System A validates ST with CAS, establishes a local session, and grants access.

When the user later visits System B, CAS sees the existing TGC, issues a new ST, and System B creates its own session without prompting for credentials.

Key CAS endpoints: /login – login page. /logout – logout. /validate – check if user is logged in. /serviceValidate – validate a Service Ticket.

CAS tickets:

TGT – Ticket‑Granting Ticket stored in CAS server session.

TGC – Cookie containing the TGT identifier.

ST – Service Ticket for a specific application.

6. OAuth 2.0

OAuth 2.0 is an open standard for delegated authorization. It issues short‑lived access tokens to third‑party apps without exposing user passwords.

Grant Types

Authorization Code – most secure, requires a backend to exchange a code for a token.

Implicit – token is returned directly to the front‑end (suitable for pure SPA).

Password Credentials – user supplies username/password to the client (only for highly trusted apps).

Client Credentials – client authenticates itself (no user context, used for service‑to‑service calls).

Typical Authorization Code flow:

User clicks login → client redirects to

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

.

User authenticates and consents; auth server redirects back with code=AUTH_CODE.

Client’s backend calls https://auth.example.com/oauth/token with grant_type=authorization_code, client_id, client_secret, and the received code.

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

Reference tables and diagrams are omitted for brevity but were present in the original article.

7. QR‑Code (Scan) Login

Three‑party flow (PC ←→ Server ←→ Mobile):

PC requests a QR code; server generates a UUID, stores it with PC device info in Redis, and returns the QR image.

Mobile app (already logged in) scans the QR code, sends the UUID and its own token to the server.

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

User confirms on mobile; server validates the temporary token, marks the QR code as “authenticated”, and issues a final token for the PC.

PC polls the server, receives the final token, and completes login.

8. One‑Click (Carrier) Login for Native Apps

Instead of SMS verification, the app obtains the device’s SIM‑card number via the carrier’s SDK (requires carrier support). The flow:

Initialize carrier SDK with AppKey and AppSecret.

SDK shows an authorization page displaying a masked phone number; user consents.

SDK returns a carrier‑issued token.

App sends the token to its backend, which calls the carrier’s API to retrieve the real phone number.

Backend logs in or registers the user based on the phone number and returns its own session/token to the app.

Supported carriers and third‑party services are listed in the original article (e.g., China Mobile, China Telecom, China Unicom, Alibaba, Chuanglan, Jiguang, Mob).

9. Summary of Authentication Methods

HTTP Basic Auth – suitable for internal networks with low security requirements.

Session‑Cookie – fits medium‑to‑large web sites (excluding native mobile apps).

Token & JWT – widely used for enterprise web services; JWT offers better performance.

SSO (CAS) – ideal for enterprises with many subsystems.

OAuth 2.0 – best for rapid user registration and third‑party login.

QR‑code login – works when PC, mobile, and backend are integrated.

One‑click login – optimized for native mobile applications.

References are provided at the end of the original article.