ACCESS TOKEN LÀ GÌ? TRÁI TIM CỦA CÁC HỆ THỐNG XÁC THỰC HIỆN ĐẠI

1. Bản Chất Của Access Token (The What)

Hãy tưởng tượng bạn đi thuê khách sạn. Khi đến quầy lễ tân, bạn phải trình Căn cước công dân (Username/Password) để chứng minh mình là ai. Lễ tân kiểm tra đúng người, họ không trả lại CCCD bắt bạn đi đâu cũng phải giơ ra, mà họ cấp cho bạn một Thẻ từ (Keycard).

Cái thẻ từ đó chính là Access Token.

Về mặt kỹ thuật, Access Token là một chuỗi ký tự được Server mã hóa và cấp phát cho Client (Trình duyệt, Mobile App) sau khi đăng nhập thành công. Client sẽ đính kèm chuỗi này vào mỗi request gửi lên Server để chứng minh: "Tôi đã đăng nhập, và tôi có quyền gọi API này".

2. Tại Sao Lại Phải Dùng Access Token? (The Why)

Giao thức HTTP là Stateless (Không lưu trạng thái). Nó mắc "chứng mất trí nhớ ngắn hạn" – request số 2 sẽ không hề biết request số 1 là ai.

Trước đây, người ta giải quyết bằng Session-Cookie: Server tạo một biến Session trên RAM và gửi ID xuống Cookie của Client. Nhưng khi hệ thống scale lên nhiều server (Load Balancing), server A lưu Session nhưng request sau lại rớt vào server B, thế là user bị văng ra ngoài.

Access Token ra đời để giải quyết bài toán này:

• Stateless Authentication: Server không cần lưu trạng thái của user trên RAM nữa. Mọi thông tin cần thiết để xác thực đã nằm gọn bên trong Token.
• Microservices Friendly: Token có thể được truyền qua lại giữa hàng chục service khác nhau (ví dụ: từ API Gateway gọi vào Payment Service). Service nào cũng có thể tự xác minh Token mà không cần chọc vào Database trung tâm.
• Phân quyền chi tiết (Scopes/Permissions): Thẻ từ khách sạn có thể cài đặt để mở cửa phòng gym, bể bơi nhưng không mở được phòng bếp. Access Token cũng vậy, nó chứa thông tin xem user được quyền read:orders hay write:users.

3. Hai Định Dạng Phổ Biến Nhất Của Access Token

1. Opaque Token (Token "Mù"): Là một chuỗi ký tự ngẫu nhiên (ví dụ: 8x0s3j...). Client cầm token này gửi lên Resource Server. Server này không thể tự dịch được chuỗi đó, mà phải gọi ngược về Authorization Server (nơi cấp token ban đầu) để hỏi xem "Cái chuỗi này ứng với user nào? Có hợp lệ không?". An toàn, dễ thu hồi, nhưng làm tăng độ trễ mạng.
2. JWT (JSON Web Token): Đây là "tiêu chuẩn vàng" hiện tại. JWT là một chuỗi mã hóa bao gồm 3 phần: Header, Payload (chứa sẵn thông tin user_id, quyền hạn, thời gian hết hạn) và Signature (chữ ký số chống giả mạo). Server nhận được JWT chỉ cần dùng Secret Key (hoặc Public Key) để verify chữ ký là biết ngay Token thật hay giả mà không cần gọi đi đâu khác.

4. Vòng Đời Của Một Access Token (The Lifecycle)

• Cấp phát: Client gửi thông tin đăng nhập (Tài khoản/Mật khẩu hoặc thông qua luồng OAuth2/OIDC). Server xác thực đúng, tạo Access Token và gửi về Client.
• Sử dụng: Client lưu trữ Token. Mỗi khi gọi API, Client nhét Token vào HTTP Header theo chuẩn:

  Authorization: Bearer <chuỗi_access_token>
  

• Xác minh (Verify): Backend nhận request, bóc Header ra, dùng thuật toán (như HS256, RS256 hoặc ML-DSA) để kiểm tra chữ ký và thời hạn sử dụng. Nếu hợp lệ, cho phép đi tiếp vào Controller.
• Hết hạn (Expiration): Access Token bắt buộc phải có tuổi thọ rất ngắn (thường từ 5 phút đến 1 tiếng). Hết giờ, Token biến thành tờ giấy lộn.

5. Góc Nhìn Bảo Mật (Security Best Practices)

Cầm được Access Token là cầm được sinh mạng của tài khoản. Do đó, việc bảo vệ nó là ưu tiên số một:

• Không bao giờ chứa dữ liệu nhạy cảm: Token (đặc biệt là JWT) chỉ được mã hóa Base64 chứ không hề bị che giấu. Bất kỳ ai bắt được chuỗi đó vứt lên jwt.io đều đọc được Payload. Tuyệt đối không nhét Password, thẻ tín dụng, hay thông tin bảo mật vào Payload.
• Vấn đề lưu trữ trên Frontend:
  • Lưu ở LocalStorage hay SessionStorage? Cực kỳ tiện, nhưng sẽ bị hacker lấy sạch trong 1 nốt nhạc nếu dính lỗi XSS.
  • Lưu ở HttpOnly Cookie? Đây là giải pháp an toàn nhất để chống XSS trên nền tảng Web, nhưng lại phải cấu hình thêm cơ chế chống CSRF.
• Bài toán Thu hồi (Revocation): Vì JWT tự xác minh (Stateless), nếu user bấm "Đăng xuất" hoặc bị ban tài khoản, cái Token đó trên lý thuyết vẫn dùng được cho đến khi hết hạn. Để giải quyết, hệ thống lớn phải dùng thêm Blacklist (lưu các Token bị cấm vào Redis) hoặc chỉnh thời gian hết hạn của Access Token xuống cực ngắn (ví dụ 5 phút) và dùng kết hợp với Refresh Token.

💡 Lời Kết

Access Token đã định hình lại hoàn toàn cách các hệ thống phân tán tương tác với nhau. Hiểu sâu về cấu trúc, cách phân phối, nơi cất giấu và đặc biệt là cách kiểm soát tuổi thọ của nó là kỹ năng bắt buộc để xây dựng một Backend System vừa chịu tải tốt (High Performance) vừa an toàn tuyệt đối (High Security).