Bài 5: SSO trong kiến trúc Microservices (API Gateway Pattern)

Trong kiến trúc Microservices, chúng ta không để mỗi service "tự bơi". Chúng ta sử dụng API Gateway làm "người gác cổng" trung tâm.

1. Vấn đề: "Chatty" (Nói chuyện quá nhiều)

Nếu bạn có 10 service (Order, Payment, User, Inventory...), và mỗi service đều gọi API đến IdP để hỏi: "Token này có hợp lệ không?", thì IdP sẽ trở thành nút thắt cổ chai (bottleneck). Hệ thống sẽ bị chậm ngay lập tức.

2. Giải pháp: Kiến trúc "Tập trung & Phân tán"

Thay vì gọi IdP liên tục, chúng ta dùng cơ chế Stateless Validation (Xác thực không trạng thái) dựa trên JWT:

1. Giai đoạn Login: Người dùng thực hiện luồng Authorization Code Flow như bài 4 để lấy Token.

2. API Gateway (Người gác cổng): Khi bạn gửi request đến hệ thống (ví dụ: POST /api/order), bạn đính kèm JWT vào Header (Authorization: Bearer <token>).

3. Xác thực tại Gateway: API Gateway nhận request, nó tự kiểm tra chữ ký của JWT (sử dụng Public Key của IdP đã lưu sẵn). Lưu ý: Gateway không gọi lại IdP vì nó đã có sẵn Public Key để giải mã token.

4. Truyền tiếp (Forwarding): Nếu token hợp lệ, Gateway sẽ "chuyển tiếp" request đó vào các Service bên trong (Order Service, Payment Service...). Lúc này, các Service bên trong chỉ cần tin tưởng vào thông tin đã được Gateway xác thực.

   Client -> API Gateway (Gateway kiểm tra chữ ký JWT) -> Service (Xử lý nghiệp vụ).

4. Tại sao cách này tối ưu cho Backend Engineer?

• Hiệu năng: Gateway không cần gọi mạng ra ngoài để xác thực, nó dùng CPU để kiểm tra chữ ký số (rất nhanh).
  

• Bảo mật: Các Microservices bên trong nằm sau Gateway, không cần tiếp xúc trực tiếp với Internet.
  

• Mở rộng: Bạn có thể scale Gateway lên bao nhiêu tùy thích.
  

  Bảng so sánh cách xác thực

| Độ trễ     | Cao (do chờ network)     | Thấp (do xử lý local)     |
| Độ phức tạp     | Cao (mỗi service phải code logic auth)     | Thấp (chỉ tập trung tại Gateway)     |


Câu hỏi tư duy cho bạn:

Nếu một ngày, bạn cần "khóa" (revoke) ngay lập tức một người dùng đang có Token hợp lệ (ví dụ: phát hiện tài khoản bị hack), nhưng Token đó vẫn chưa hết hạn (vì nó là stateless nên không thể xóa trực tiếp trên server). Theo bạn, làm sao để xử lý tình huống "cấp bách" này trong kiến trúc Microservices? (Gợi ý: Hãy nghĩ về Blacklist hoặc Redis).

Nếu bạn đã nắm được luồng Gateway này, chúng ta đã hoàn thành xong phần cốt lõi của lý thuyết SSO. Bạn có muốn chúng ta chuyển sang phần thực hành với Laravel hoặc Go (ngôn ngữ bạn đang sử dụng) để hiện thực hóa các kiến thức này không?