FE Master 2026

DAY 73🇯🇵 認証 (OAuth2/JWT)

Xác thực: Authentication & OAuth 2.0

73%

Quảng cáo • Advertisement

📢 Sponsor Ad

Google AdSense

🎯 Mục tiêu bài học

Đăng nhập bằng Google/Facebook hoạt động thế nào?

1. Các phương pháp xác thực (Authentication Factors)

Something you know: Password, PIN.
Something you have: Điện thoại (OTP), Token key, Thẻ từ.
Something you are: Vân tay, Mống mắt, FaceID (Biometrics).

MFA (Multi-Factor Authentication): Phải kết hợp ít nhất 2 loại trên. (User + Token là MFA. User + Pass 2 lớp vẫn là 1FA).

2. Session vs Token (JWT)

Đặc điểm	Session-based (Cổ điển)	Token-based (Hiện đại/Mobile)
Lưu trạng thái	Server lưu SessionID trong RAM/Memcached. (Stateful).	Server không lưu gì cả. Token chứa hết thông tin. (Stateless).
Client lưu	Cookie.	LocalStorage hoặc Cookie.
Scale	Khó. Cần Sticky Session hoặc Redis chung.	Dễ. Token mang đi server nào cũng verify được.
Thu hồi	Dễ. Xóa Session trên server là xong.	Khó. Token đã phát ra thì không thu hồi được cho đến khi hết hạn (hoặc phải dùng Blacklist).

3. Giải phẫu JWT (JSON Web Token)

Chuỗi aaaaa.bbbbb.ccccc gồm 3 phần:

Header: Thuật toán ký (HS256).
Payload: Data (UserID, Role, ExpireTime). Dạng Base64 (Ai cũng decode đọc được -> Đừng để lộ thông tin mật).
Signature: $HMACSHA256(Header + Payload, SecretKeepInServer)$. Dùng để chống sửa đổi.

Nếu Hacker sửa Payload (Role: Admin), chữ ký sẽ sai -> Server từ chối.

4. OAuth 2.0 - "Đưa chìa khóa phụ cho người lạ"

Kịch bản: Bạn muốn chơi Candy Crush bằng nick Facebook, nhưng không muốn đưa Password Facebook cho Candy Crush.

Authorization Code Flow (Chuẩn nhất)

Candy Crush (Client) chuyển hướng bạn sang trang Login của Facebook (Auth Server).
Bạn đăng nhập trên Facebook và bấm "Allow".
Facebook chuyển hướng bạn về lại Candy Crush kèm theo một cái Authorization Code.
Candy Crush (Back-end) cầm Code này bí mật gọi lên Facebook đổi lấy Access Token.
Dùng Access Token để lấy Avatar, Tên từ API Facebook.

sequenceDiagram participant User participant Client as CandyCrush participant Auth as Facebook User->>Client: Click "Login with Facebook" Client->>Auth: Redirect to Login Page User->>Auth: Login & Approve Auth->>Client: Redirect with Auth Code Client->>Auth: Exchange Code for Token Auth->>Client: Access Token Client->>Auth: Get User Info (Avatar)

Tại sao cần bước đổi Code lấy Token? Để Token không bao giờ bị lộ trên trình duyệt (Front-end). Code chỉ dùng 1 lần và hết hạn cực nhanh.

5. OAuth 2.0 vs OpenID Connect (OIDC)

OAuth 2.0: Chỉ để Ủy quyền (Authorization). (Vd: Cho phép App in ảnh lấy ảnh từ Facebook). Nó không quan tâm "Ai đang đăng nhập", nó chỉ quan tâm "Đưa chìa khóa đây".
OIDC: Là lớp định danh (Identity) đắp lên trên OAuth 2.0. Nó trả về id_token chứa thông tin User (Tên, Email, Avatar). Dùng để Đăng nhập (Authentication).

👉 "Login with Google" chính là OIDC (OAuth 2.0 + Identity Layer).

🔥 Interview Q&A

Q: Tại sao không nên lưu JWT trong LocalStorage?

A: Vì Javascript đọc được LocalStorage -> Dễ bị tấn công XSS lấy cắp Token. Nên lưu trong HttpOnly Cookie (JS không đọc được, chống XSS), nhưng phải cẩn thận với CSRF.

6. Sai số trong sinh trắc học (FAR vs FRR)

FAR (False Acceptance Rate): Tỉ lệ chấp nhận sai (Hacker đặt vân tay lên mà máy tưởng là chủ nhà). -> Nguy hiểm cho bảo mật.
FRR (False Rejection Rate): Tỉ lệ từ chối sai (Chủ nhà đặt vân tay lên mà máy không nhận). -> Gây khó chịu cho User.

👉 Câu hỏi thi: Để tăng tính bảo mật, ta nên chỉnh thiết bị để giảm chỉ số nào? Đáp án: Giảm FAR.

📝 Luyện tập Part B (Exam Drills):

Câu hỏi: OAuth 2.0 có thay thế được cho Password không?
Đáp án
Không. OAuth 2.0 là cơ chế Ủy quyền (Authorization), không phải định danh (nếu không có lớp OIDC).