Từ Monolith đến Microservices: Tại sao Phantom Token là lựa chọn tối ưu cho Authentication?

Sun, 03 May 2026 10:00:00 +0700

3 mẫu kiến trúc xác thực kinh điển trong ứng dụng Web

Hầu hết các hệ thống xác thực (Authentication) cho ứng dụng Web hiện nay đều xoay quanh 3 mẫu thiết kế nền tảng:

Stateful Session Pattern

Đây là mô hình kinh điển nhất, gắn liền với các framework Web truyền thống như ASP.NET MVC hay PHP.

Sau khi đăng nhập, server tạo một phiên làm việc (Session) và lưu vào bộ nhớ (RAM/Redis). Client chỉ nhận về một Session ID vô nghĩa, được lưu trong HttpOnly Cookie.

Ưu điểm: Cực kỳ bảo mật — dữ liệu thực (Claims) không bao giờ rời khỏi server. Muốn thu hồi phiên làm việc? Chỉ cần xóa Session ở server là xong.
Nhược điểm: Triển khai Session trong Microservices đòi hỏi Shared Cache hoặc cấu hình Sticky Sessions trên Load Balancer, đồng thời gây rắc rối khi xử lý các chính sách SameSite Cookie trên đa domain. Điều này làm mất đi tính Stateless và sự độc lập của mỗi service.

sequenceDiagram
participant B as Browser
participant S as Server
participant C as Cache/Database
B->>S: 1. Gửi credentials (user/pass)
S->>S: 2. Xác thực thông tin
S->>C: 3. Tạo Session, lưu Session ID
S-->>B: 4. Trả về HttpOnly Cookie (Session ID)
B->>S: 5. Gửi request + Cookie (Session ID)
S->>C: 6. Kiểm tra Session ID
S-->>B: 7. Trả về Resource

Token-by-Value Pattern (Stateless JWT)

Mô hình này bùng nổ cùng với sự phát triển của Single Page Application và Mobile App.

Toàn bộ thông tin người dùng được đóng gói vào một JWT và ký số. Server không lưu trạng thái (Stateless) — client tự giữ token và gửi kèm trong header Authorization.

Ưu điểm: Scale rất tốt vì server không cần truy vấn DB/cache để xác thực. Phù hợp với kiến trúc Microservices.
Nhược điểm: Hacker có thể giải mã Base64 để đọc nội dung bên trong (rò rỉ PII). Một khi JWT đã được phát ra, gần như không có cách nào thu hồi trước khi hết hạn. Việc để lộ cấu trúc Claims hoặc ID người dùng trong JWT (dù đã mã hóa Base64) là một điểm trừ lớn khi Audit.

sequenceDiagram
participant B as Browser
participant S as Server
participant R as Resource API
B->>S: 1. Gửi credentials (user/pass)
S->>S: 2. Xác thực thông tin
S-->>B: 3. Tạo JWT (chứa Claims, ký số), trả về Client
B->>B: 4. Lưu JWT (LocalStorage/Memory)
B->>R: 5. Gửi request + Authorization: Bearer JWT
R->>R: 6. Giải mã, kiểm tra chữ ký JWT (Stateless)
R-->>B: 7. Trả về Resource

Token-by-Reference Pattern (Opaque Token)

Thường dùng trong các hệ thống yêu cầu bảo mật cao hoặc các Identity Server chuyên dụng.

Server trả về một chuỗi ngẫu nhiên vô nghĩa (Opaque Token), còn thông tin thực sự được lưu tập trung tại Identity Server.

Ưu điểm: Client không chứa bất kỳ dữ liệu nhạy cảm nào.
Nhược điểm: Mỗi lần cần xác thực, Resource API phải gọi ngược về Identity Server (Introspection) để giải mã token — tạo ra “điểm nghẽn” khi traffic lớn.

sequenceDiagram
participant B as Browser
participant S as Server
participant I as Identity Server
participant R as Resource API
B->>S: 1. Gửi credentials (user/pass)
S->>I: 2. Xác thực, tạo Opaque Token, lưu vào cache
I-->>B: 3. Trả về Opaque Token (chuỗi ngẫu nhiên)
B->>R: 4. Gửi request + Opaque Token
R->>I: 5. Gọi Introspection để giải mã token
I-->>R: 6. Trả về Claims thông tin người dùng
R-->>B: 7. Trả về Resource

Giải pháp tối ưu: Phantom Token Pattern

Nhận ra điểm yếu của cả hai hướng trên, Phantom Token Pattern ra đời như một sự kết hợp thông minh: dùng Opaque Token làm lớp bảo mật bên ngoài, và JWT làm động cơ hiệu năng bên trong.

Cơ chế vận hành

Mẫu thiết kế này chia hệ thống thành hai vùng rõ rệt: Public Zone (không tin cậy) và Private Zone (tin cậy).

Cấp phát: Khi đăng nhập, Identity Server tạo JWT đầy đủ claims nhưng không gửi đi. Nó lưu JWT vào cache và chỉ trả về cho Client một Opaque Token.
Gửi request: Client gửi request kèm Opaque Token đến API Gateway.
Hoán đổi token: Tại API Gateway (nằm ở biên mạng), Gateway nhận Opaque Token và gọi sang Identity Server để đổi lấy JWT tương ứng.
Xử lý nội bộ: Gateway thay thế Opaque Token bằng JWT trong header rồi forward vào các Microservices bên trong.

sequenceDiagram
box rgb(255, 245, 230) Public Zone
participant B as Browser
participant N as Internet
end
box rgb(230, 245, 255) Private Zone
participant G as API Gateway
participant I as Identity Server
participant M as Microservices
end
B->>N: 1. Gửi credentials (user/pass)
N->>G: 2. Chuyển tiếp tới Gateway
G->>I: 3. Điều phối xác thực
I->>I: 4. Xác thực, tạo JWT, lưu vào cache
I-->>G: 5. Trả về Opaque Token
G-->>B: 6. Trả về Opaque Token cho Client
B->>G: 7. Gửi request + Opaque Token (qua Internet)
G->>I: 8. Exchange: gửi Opaque Token
I-->>G: 9. Trả về JWT tương ứng
G->>G: 10. Thay Opaque Token bằng JWT trong header
G->>M: 11. Forward request + JWT
M->>M: 12. Xử lý Stateless (như Token-by-Value)
M-->>B: 13. Trả về Resource

Tại sao gọi là “Phantom”?

Vì đối với Client, JWT hoàn toàn không tồn tại. Nó như một “bóng ma” — chỉ xuất hiện và lưu hành bên trong vùng mạng nội bộ của hệ thống.

Ưu điểm vượt trội

Bảo mật đa lớp (Defense in Depth & PII Protection): Thông tin nhạy cảm (User ID, Role, Email…) được đóng gói trong JWT và chỉ lưu hành trong mạng nội bộ. Client chỉ nhận Opaque Token vô nghĩa, triệt tiêu hoàn toàn nguy cơ rò rỉ dữ liệu cá nhân (PII) ra Internet.
Thu hồi quyền truy cập tức thì (Immediate Revocation): Khác với JWT truyền thống khó thu hồi trước khi hết hạn, Opaque Token có thể bị vô hiệu hóa ngay lập tức tại API Gateway hoặc Identity Server, giúp kiểm soát phiên làm việc của người dùng chặt chẽ hơn.
Tối ưu hiệu năng Microservices: Các service phía sau Gateway nhận được JWT đã được “giải mã sẵn”, cho phép xử lý Stateless hoàn toàn mà không cần gọi ngược về Identity Server (Introspection). Ngoài ra, request từ Client qua mạng cũng nhẹ hơn nhờ payload của Opaque Token rất gọn.
Tách biệt trách nhiệm (Separation of Concerns): Identity Server lo việc phát hành/định danh. API Gateway lo việc chuyển đổi (Introspection). Microservices chỉ quan tâm đến Business Logic với một JWT sạch.

Khi nào nên dùng?

Phantom Token Pattern đặc biệt phù hợp khi bạn xây dựng hệ thống Microservices hiện đại, có yêu cầu bảo mật cao, và muốn tách biệt rõ ràng trách nhiệm giữa Security và Business Logic.

Lời kết: Phantom Token không chỉ là một kỹ thuật xác thực — nó là tư duy thiết kế bảo mật theo chiều sâu. Vừa đạt được sự an toàn của Opaque Token, vừa giữ được hiệu năng của JWT.

Session on Huy Vũ