Kiến trúc lựa chọn — tổng hợp

Sau khi đã hiểu cơ chế của từng phần, đây là sơ đồ và các bảng tổng hợp dùng để ra quyết định kiến trúc thực tế.

flowchart TD
    A[Bắt đầu thiết kế/review Auth] --> B{Client là gì?}
    B -->|Web app riêng, một domain| C[Session + Redis + httpOnly cookie]
    B -->|Mobile / nhiều service / third-party| D[JWT access token ngắn hạn]
    C --> E{Sau này có cần API riêng cho mobile?}
    E -->|Có| F[Hybrid: session cho web + JWT cho API]
    D --> G{Có người dùng đăng nhập không?}
    G -->|Có| H[OAuth 2.0 Authorization Code + PKCE]
    G -->|Không, machine-to-machine| I[OAuth 2.0 Client Credentials]
    H --> J{Cần biết danh tính user, không chỉ quyền truy cập?}
    J -->|Có| K[Dùng OpenID Connect trên nền OAuth 2.0 — thêm ID Token]
    J -->|Chỉ cần quyền truy cập tài nguyên| L[OAuth 2.0 thuần là đủ]
    F --> M[Refresh token: httpOnly cookie / Keychain-Keystore + rotation]
    K --> M

Session vs JWT vs Hybrid

Tiêu chí	Session (lưu ở server)	JWT (stateless)
Nơi lưu trạng thái	Server (thường dùng Redis)	Không lưu — token tự chứa toàn bộ thông tin
Thu hồi ngay lập tức	Dễ — chỉ cần xoá session ở server	Khó — token còn hạn vẫn dùng được
Phù hợp với	Web app riêng, một domain	Mobile app, API công khai, nhiều service
Mặc định 2026	Hybrid: session/refresh token sống lâu, có thể thu hồi, kết hợp với JWT access token sống ngắn cho từng request

OAuth 2.0 — chọn grant type nào

Grant type	Khi nào dùng
Authorization Code + PKCE	Mọi ứng dụng có người dùng đăng nhập (web, SPA, mobile, desktop) — chuẩn mặc định hiện nay, chi tiết ở trang OAuth 2.0 & PKCE
Client Credentials	Giao tiếp máy-với-máy (machine-to-machine), không có người dùng liên quan
Implicit Grant / Password Grant	Đã lỗi thời (deprecated) — nếu thấy đề xuất dùng hai loại này, cần xem lại ngay

OAuth 2.0 vs OpenID Connect vs SAML

• OAuth 2.0: framework uỷ quyền (authorization) — trả lời câu hỏi "ứng dụng được phép làm gì với dữ liệu của người dùng".
• OpenID Connect (OIDC): lớp xác thực danh tính (authentication) xây dựng trên nền OAuth 2.0, bổ sung ID Token — chi tiết ở trang OpenID Connect.
• SAML: chuẩn cũ hơn, dựa trên XML, chủ yếu dùng khi phải tích hợp với một identity provider (IdP) doanh nghiệp đã tồn tại từ trước.
• Quy tắc chung: mặc định chọn OIDC; chỉ dùng SAML khi bắt buộc phải tương thích với một IdP cũ chỉ hỗ trợ SAML.

Lưu trữ token

Đây là nơi phần lớn lỗ hổng bảo mật liên quan đến auth thực sự xuất phát:

Nền tảng	Access token	Refresh token
Web (trình duyệt)	Lưu trong bộ nhớ (in-memory)	Cookie có cờ httpOnly + Secure + SameSite=Strict
Mobile	Bộ nhớ hoặc secure storage	Keychain (iOS) / Keystore (Android)
Tuyệt đối tránh	—	localStorage — bất kỳ đoạn JavaScript nào chạy trên domain (kể cả do lỗ hổng XSS) đều đọc được, dẫn đến mất tài khoản vĩnh viễn nếu bị khai thác

Refresh token rotation: mỗi lần dùng refresh token để lấy access token mới, token cũ lập tức bị vô hiệu hoá và một token mới được cấp. Nếu một refresh token đã bị xoay vòng (rotate) mà vẫn bị dùng lại, hệ thống sẽ kích hoạt cơ chế phát hiện tái sử dụng (reuse detection) và thu hồi toàn bộ chuỗi token liên quan — đây là dấu hiệu token đã bị đánh cắp.