Auth Flow

Cơ chế xác thực (authentication) và phân quyền (authorization) trên web không được thiết kế hoàn chỉnh ngay từ đầu, mà là một chuỗi các giải pháp nối tiếp nhau: mỗi giải pháp giải quyết một vấn đề cụ thể của giải pháp trước, đồng thời để lộ ra một vấn đề mới, từ đó thúc đẩy giải pháp tiếp theo ra đời.

mermaid

flowchart TD
    A["HTTP Basic Auth<br/>gửi password ở mỗi request"] -->|"lộ trên đường truyền,<br/>không thu hồi (revoke) được"| B["Session + Cookie<br/>server lưu trạng thái đăng nhập"]
    B -->|"không thể chia sẻ password<br/>cho ứng dụng bên thứ ba"| C["OAuth 1.0<br/>uỷ quyền có phạm vi (scope)"]
    C -->|"chữ ký mật mã (signature)<br/>quá phức tạp, dễ cài sai"| D["OAuth 2.0<br/>bearer token + TLS"]
    D -->|"chỉ giải quyết authorization,<br/>không định nghĩa 'đăng nhập'"| E["OpenID Connect (OIDC)<br/>bổ sung ID Token"]
    E -->|"mobile app không giữ được<br/>client secret, bị đánh cắp authorization code"| F["PKCE<br/>code_verifier / code_challenge"]
    F -->|"session lưu ở server<br/>không scale tốt cho hệ thống phân tán"| G["JWT (stateless token)<br/>tự chứa toàn bộ thông tin"]
    G -->|"token đã cấp không thể<br/>thu hồi trước khi hết hạn"| H["Hybrid (hiện tại)<br/>JWT ngắn hạn + refresh token có thể thu hồi"]

#	Giải pháp	Vấn đề được giải quyết	Vấn đề mới phát sinh
1	HTTP Basic Auth	Xác thực đơn giản qua giao thức HTTP	Phải gửi lại mật khẩu ở mỗi request, không có khái niệm "đăng xuất"
2	Session + Cookie	Không cần gửi lại mật khẩu, server chủ động kiểm soát đăng nhập/đăng xuất	Nhiều server cần chia sẻ session (Redis, sticky session)
3	OAuth 1.0 (2007/2010)	Ứng dụng bên thứ ba truy cập được dữ liệu mà người dùng không phải đưa mật khẩu	Cơ chế ký (signature) bằng mật mã quá phức tạp, khó triển khai đúng
4	OAuth 2.0 (2012)	Bỏ chữ ký, dùng bearer token + TLS, đơn giản hoá triển khai	Chỉ định nghĩa authorization, không chuẩn hoá khái niệm "đăng nhập"
5	OpenID Connect — OIDC (2014)	Chuẩn hoá xác thực danh tính bằng ID Token, xây trên nền OAuth 2.0	Ứng dụng native/mobile không giữ được client secret an toàn
6	PKCE (2015)	Ngăn kẻ tấn công đánh cắp authorization code trên mobile	Chưa giải quyết bài toán mở rộng cho hệ thống phân tán
7	JWT (stateless token)	Không cần session store dùng chung, phù hợp hệ thống phân tán/microservices	Không thể thu hồi một token đã cấp trước khi nó hết hạn
8	Hybrid (hiện tại, 2026)	Kết hợp access token JWT sống ngắn (5–15 phút) với refresh token có thể thu hồi ngay	— (kiến trúc mặc định hiện nay)

Bài học rút ra: mỗi lớp giải pháp mới đều là một sự đánh đổi (trade-off), không phải một bước tiến tuyệt đối. Khi đánh giá một thiết kế auth — kể cả do AI đề xuất — nên đặt ba câu hỏi: nó đang giải quyết vấn đề cụ thể nào, cái giá phải trả là gì, và vấn đề mới mà nó có thể tạo ra có thực sự liên quan đến hệ thống đang xây dựng hay không.

Các trang tiếp theo đi sâu vào cơ chế hoạt động thật sự của từng giải pháp trong chuỗi trên — đọc theo thứ tự trong sidebar để mạch kiến thức liền nhau (dùng nút "Trang sau" ở cuối mỗi trang).

Auth Flow ​

Auth Flow