Giao Thức Và Tiêu Chuẩn Hóa: Hệ Thống Vận Chuyển Định Danh Phân Tán
Trong kiến trúc Microservices, thách thức lớn nhất không phải là xác thực người dùng, mà là làm thế nào để chuyển tiếp (propagate) định danh đó qua hàng chục dịch vụ khác nhau một cách an toàn và hiệu quả. Các giao thức hiện đại như OAuth 2.0 và OpenID Connect (OIDC), cùng với cấu trúc dữ liệu JWT, chính là lời giải cho bài toán này.
1. JSON Web Token (JWT): Thực Thể Dữ Liệu Tự Chứa (Self-contained)
JWT không phải là một giao thức, mà là một tiêu chuẩn mở (RFC 7519) định nghĩa cách thức truyền tin an toàn giữa các bên dưới dạng một đối tượng JSON.
Cấu trúc toán học của JWT
Một JWT được cấu thành từ ba phần tách biệt bởi dấu chấm (.), được mã hóa Base64URL: $Header.Payload.Signature$.
Header: Chứa thông tin về thuật toán ký (ví dụ: RS256, HS256).
Payload (Claims): Chứa dữ liệu thực thể (User ID, Roles, Expiry).
Signature: Đây là phần ứng dụng trực tiếp của Kỳ 2. Nếu thuật toán là RSA, chữ ký $S$ được tính toán như sau:
$$S = Sign_{K_{priv}}(H(Header) + "." + H(Payload))$$
Đặc tính Stateless và Khả năng xác thực Offline
Nhờ có chữ ký số, JWT mang tính chất "tự chứa". Một Resource Server (Microservice) khi nhận được JWT có thể tự thực hiện quy trình:
Giải mã phần Header để biết thuật toán.
Dùng Public Key của Identity Provider để xác minh chữ ký $S$.
Nếu chữ ký hợp lệ, dịch vụ có thể tin tưởng hoàn toàn vào các thông tin trong Payload mà không cần thực hiện một truy vấn mạng (network call) nào tới máy chủ xác thực trung tâm.
2. OAuth 2.0: Khung Ủy Quyền (Authorization Framework)
OAuth 2.0 (RFC 6749) giải quyết bài toán Delegated Authorization (Ủy quyền đại diện). Giao thức này cho phép một ứng dụng bên thứ ba truy cập tài nguyên của người dùng trên một dịch vụ khác mà không cần biết mật khẩu của người dùng đó.
Các thực thể trong OAuth 2.0:
Resource Owner: Người dùng.
Client: Ứng dụng muốn truy cập tài nguyên.
Resource Server: Nơi lưu trữ dữ liệu (API).
Authorization Server: Máy chủ cấp phát Token.
Cơ chế hoạt động:
OAuth 2.0 tập trung vào việc cấp phát Access Token. Token này giống như một chiếc chìa khóa vạn năng có thời hạn và phạm vi (Scope) giới hạn. Giao thức này sử dụng các lớp bảo mật mật mã học (như TLS/SSL) để bảo vệ quá trình trao đổi Token trên đường truyền.
3. OpenID Connect (OIDC): Lớp Định Danh (Identity Layer)
Trong khi OAuth 2.0 được thiết kế cho việc Ủy quyền (Authorization), nó lại thiếu sót khả năng Xác thực (Authentication) — tức là trả lời câu hỏi "Người dùng này là ai?". OIDC ra đời như một lớp bổ sung phía trên OAuth 2.0 để chuẩn hóa việc định danh.
Sự khác biệt cốt lõi:
OAuth 2.0 trả về
Access Token(Dùng để truy cập API).OIDC trả về thêm một
ID Token(Luôn là định dạng JWT).
OIDC định nghĩa các điểm cuối (Endpoints) chuẩn hóa như /userinfo để ứng dụng có thể lấy thông tin chi tiết về người dùng một cách thống nhất, bất kể hệ thống Identity Provider phía sau là gì.
4. SAML 2.0: Tiêu chuẩn dựa trên XML
Trước khi OIDC trở nên phổ biến, SAML (Security Assertion Markup Language) là tiêu chuẩn thống trị trong các môi trường doanh nghiệp (Enterprise).
Cơ chế: Trao đổi các "lời khẳng định" (Assertions) về danh tính dưới dạng tài liệu XML được ký số.
Đặc điểm: SAML rất mạnh mẽ và hỗ trợ các kịch bản SSO phức tạp, nhưng nó khá nặng nề và khó triển khai trên các ứng dụng di động hoặc Single Page Applications (SPA) so với OIDC/JWT.
5. Tổng kết: Sự hội tụ của Mật mã học và Giao thức
Sự an toàn của một hệ thống định danh hiện đại phụ thuộc vào sự phối hợp nhịp nhàng giữa ba tầng:
Toán học (Cryptography): Đảm bảo tính toàn vẹn và xác thực thông qua Hashing và Digital Signature.
Cấu trúc (Data Format): JWT đóng gói toán học vào một định dạng dễ trao đổi.
Quy trình (Protocols): OAuth 2.0/OIDC định nghĩa cách thức các thực thể tương tác để trao đổi JWT một cách an toàn.
Việc hiểu rõ mối quan hệ này giúp các kiến trúc sư phần mềm đưa ra quyết định đúng đắn khi lựa chọn giải pháp bảo mật cho hệ thống phân tán, đảm bảo tính bảo mật (Confidentiality) mà vẫn duy trì được hiệu suất cao.