Bài 3: Giải mã "Chìa khóa" - Token trong SSO

Trong cơ chế cũ (Session-based), server lưu trữ thông tin đăng nhập trong RAM (Session). Nhưng trong SSO và các kiến trúc hiện đại (như Microservices mà bạn đang tìm hiểu cho hệ thống), việc dùng Session rất khó mở rộng (scale).

Do đó, chúng ta dùng Token. Hãy coi Token là một "thẻ bài" được mã hóa, chứa mọi thông tin cần thiết về bạn.

1. JWT (JSON Web Token) - Tiêu chuẩn vàng

Trong OIDC, JWT là định dạng phổ biến nhất. Một JWT trông giống như một chuỗi ký tự ngẫu nhiên, nhưng thực chất nó có 3 phần được ngăn cách bởi dấu chấm .:

Header.Payload.Signature

• Header: Chứa thông tin về loại token (thường là JWT) và thuật toán mã hóa (ví dụ: RS256, HS256).
• Payload: Đây là phần "nội dung" chứa thông tin (Claims) về người dùng. Ví dụ: sub (user ID), exp (thời gian hết hạn), email, role (vai trò: admin, user).
• Signature: Đây là phần quan trọng nhất để bảo mật. Nó là chữ ký số của IdP. Nhờ có nó, hệ thống SP mới tin tưởng rằng: "À, token này đúng là do IdP cấp, không phải ai đó tự vẽ ra".

2. Các loại Token trong luồng OIDC

Khi bạn đăng nhập thành công qua OIDC, IdP thường không chỉ trả về 1 mà là 2 hoặc 3 loại token:

1. ID Token: Đây là "chứng minh thư". Nó chứa thông tin định danh người dùng. Dùng để SP biết bạn là ai.
2. Access Token: Đây là "chìa khóa vào cửa". Nó dùng để cấp quyền truy cập vào các API cụ thể (ví dụ: GET /api/v1/orders).
3. Refresh Token: Đây là "vé gia hạn". Vì Access Token thường có thời gian sống rất ngắn (ví dụ: 15 phút) để bảo mật, khi nó hết hạn, bạn dùng Refresh Token để xin một Access Token mới mà không cần bắt người dùng đăng nhập lại.

3. Quy trình "Tin tưởng" (The Trust Flow)

Tại sao SP (Service Provider) lại tin tưởng token từ IdP?

• Public/Private Key: IdP giữ Private Key để ký vào Token. SP giữ Public Key của IdP.
• Khi SP nhận được Token, nó dùng Public Key để kiểm tra chữ ký. Nếu chữ ký khớp -> Token hợp lệ. Đây là lý do tại sao hệ thống có thể xác thực lẫn nhau mà không cần gửi mật khẩu qua lại.

Tóm tắt cho kỹ sư:

• JWT là định dạng, Token là thực thể.
• ID Token để biết bạn là ai.
• Access Token để gọi API.
• Refresh Token để duy trì phiên làm việc không gián đoạn.

Thử thách tư duy cho bạn: Nếu một hacker đánh cắp được Access Token của bạn, họ có thể đóng giả bạn trong 15 phút. Theo bạn, làm sao để hệ thống giảm thiểu rủi ro này ngoài việc đặt thời gian sống (TTL) thật ngắn cho Token?

Nếu bạn đã nắm vững cấu trúc của Token, hãy cho tôi biết để chúng ta chuẩn bị sang Bài 4: Luồng Authorization Code Flow – luồng quan trọng nhất mà mọi developer phải nằm lòng khi tích hợp SSO.