Trong phát triển phần mềm hiện đại, việc xác thực người dùng và bảo mật API là yêu cầu cốt lõi. JWT là một tiêu chuẩn mở giúp truyền claims giữa các hệ thống dưới dạng nhỏ gọn và URL-safe. Mức độ an toàn phụ thuộc vào cách ký, mã hóa, xác minh và quản lý token.. Cùng FPT.AI tìm hiểu JWT là gì, cấu trúc, cách hoạt động, ứng dụng cũng như những lưu ý quan trọng khi triển khai.
JWT là gì?
JWT (JSON Web Token) là định dạng token chuẩn hóa dùng để biểu diễn một tập hợp claims. Token có thể được ký hoặc bảo vệ tính toàn vẹn bằng JWS, hoặc được mã hóa bằng JWE. Thông tin này có thể được xác minh về tính toàn vẹn, bên nhận chỉ nên sử dụng claims sau khi xác minh chữ ký, thuật toán, thời hạn và các điều kiện phát hành token.
JWT thường được sử dụng trong các bài toán:
- Xác thực người dùng (Authentication)
- Phân quyền truy cập (Authorization)
- Trao đổi thông tin giữa các hệ thống
- Bảo vệ API và dịch vụ Microservices

Ví dụ thực tế về JWT khi đăng nhập:
- Người dùng nhập username và password tại trang đăng nhập.
- Server kiểm tra thông tin đúng, tạo ra một chuỗi JWT (ví dụ: eyJhbGciOi…) và gửi về cho ứng dụng của bạn.
- Ở các lượt truy cập sau (xem hồ sơ, mua hàng…), ứng dụng chỉ cần gửi kèm chuỗi JWT này trong header của request.Server không bắt buộc truy vấn kho session ở mỗi request, nhưng vẫn có thể cần kiểm tra trạng thái tài khoản hoặc cơ chế thu hồi token.
>>> Tìm hiểu thêm: OAuth 2.0 là gì?
JWT, JWS và JWE khác nhau như thế nào?
JWT, JWS và JWE đều thuộc nhóm tiêu chuẩn JSON Web Token, nhưng khác nhau về mục đích và cách bảo vệ dữ liệu.
- JWT (JSON Web Token): Chuẩn dùng để biểu diễn và truyền tải các thông tin dưới dạng claim giữa các hệ thống.
- JWS (JSON Web Signature): JWT được ký số, giúp xác minh nguồn gửi và phát hiện dữ liệu bị chỉnh sửa, nhưng nội dung vẫn có thể đọc được.
- JWE (JSON Web Encryption): JWT được mã hóa, giúp bảo mật nội dung và ngăn người không có quyền truy cập dữ liệu.
Tóm lại, JWT là định dạng token, còn JWS và JWE là hai cơ chế bảo vệ token bằng chữ ký hoặc mã hóa.
Vì sao JWT được sử dụng phổ biến?
Cơ chế xác thực bằng JWT (JWT authentication) trở thành một trong những cơ chế phổ biến nhất hiện nay nhờ nhiều ưu điểm trong quá trình triển khai và vận hành hệ thống.
- Không cần lưu trạng thái phiên trên Server (Stateless): JWT có thể giảm nhu cầu lưu phiên tập trung, hỗ trợ triển khai hệ thống phân tán; đổi lại, việc thu hồi token cần cơ chế bổ sung.
- Kích thước nhỏ gọn: JWT thường được gửi qua Authorization header hoặc cookie bảo mật. Không nên đặt token trong URL.
- Hoạt động tốt với RESTful API: Đây là cơ chế xác thực được sử dụng phổ biến trong các API hiện đại và ứng dụng di động.
- Phù hợp với kiến trúc Microservices: Các dịch vụ khác nhau đều có thể tự xác minh JWT mà không cần truy vấn một máy chủ lưu Session.
- Độc lập với ngôn ngữ lập trình: JWT được hỗ trợ bởi hầu hết các nền tảng như Java, .NET, Python, PHP, Node.js hay Go.
- Dễ tích hợp Single Sign-On (SSO): Người dùng chỉ cần đăng nhập một lần để sử dụng nhiều hệ thống khác nhau.

Cấu trúc của JWT gồm những thành phần nào?
JWT được biểu diễn theo JWS Compact thường gồm ba phần: Header, Payload và Signature.
1. Header
Phần Header thường chứa 2 thông tin cơ bản: loại token (mặc định là JWT) và Header có thể khai báo thuật toán như HS256, RS256 hoặc ES256. Máy chủ phải giới hạn sẵn danh sách thuật toán được chấp nhận.
|
JSON
{
“alg”: “HS256”,
“typ”: “JWT”
}
|
Đoạn JSON này sau đó được mã hóa Base64Url để tạo thành phần đầu tiên của JWT.
2. Payload
Payload chứa các Claims (các câu tuyên bố về đối tượng, thường là người dùng) và các dữ liệu bổ sung. Có 3 loại claims:
-
- Registered claims: Các thông tin được chuẩn hóa như iss, sub, aud, exp, nbf, iat và jti.
- Public claims: Các thông tin do bạn tự định nghĩa, tránh trùng lặp qua các chuẩn đặt tên.
- Private claims: Thông tin tùy chỉnh được chia sẻ giữa các bên (ví dụ: user_id, role).
|
JSON
{
“sub”: “1234567890”,
“name”: “Nguyen Van A”,
“role”: “admin”,
“exp”: 1719878400
}
|
Lưu ý: Payload chỉ được mã hóa Base64URL, không được mã hóa dữ liệu. Vì vậy bất kỳ ai cũng có thể giải mã và đọc nội dung của Payload.
3. Signature
Signature giúp phát hiện token bị chỉnh sửa và xác minh nguồn phát hành, nhưng không làm Payload trở nên bí mật. Để tạo chữ ký, hệ thống lấy phần Header đã mã hóa, Payload đã mã hóa, kết hợp với một chuỗi khóa bí mật (Secret Key) và đưa qua thuật toán mã hóa được khai báo ở Header.
Chữ ký được tính theo công thức:
|
Plaintext
HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),
secret_key
)
|

JWT hoạt động như thế nào?
JWT hoạt động theo cơ chế xác thực không lưu trạng thái (stateless authentication). Thay vì lưu thông tin phiên đăng nhập trên máy chủ như Session, máy chủ chỉ cần tạo một token và gửi cho người dùng. Mỗi lần truy cập sau đó, token sẽ được gửi kèm theo yêu cầu để xác minh danh tính.
Để hiểu rõ JWT hoạt động như thế nào, hãy cùng xem cơ chế xác thực diễn ra qua quy trình 4 bước đơn giản dưới đây:
- Bước 1 – Đăng nhập: Người dùng gửi thông tin đăng nhập (email/password) lên Server.
- Bước 2 – Khởi tạo Token: Server xác thực thông tin thành công, tạo JWT chứa thông tin người dùng và ký bằng Secret Key, sau đó trả JWT về cho Client.
- Bước 3 – Lưu trữ & Truy vấn: Vị trí lưu token cần được lựa chọn theo mô hình đe dọa. LocalStorage có rủi ro khi xảy ra XSS; cookie HttpOnly giảm khả năng JavaScript đọc token nhưng cần kiểm soát CSRF. Mỗi khi gọi API cần xác thực, Client đính kèm JWT vào HTTP Header dạng: Authorization: Bearer <token>
Lưu ý: Chỉ truyền token qua HTTPS và không ghi nguyên token vào log. - Bước 4 – Xác minh Chữ ký: Server dùng khóa xác minh phù hợp để kiểm tra chữ ký, đồng thời xác thực alg, exp, nbf, iss, aud và các claims bắt buộc.
- Nếu chữ ký khớp: Request hợp lệ, xử lý và trả về kết quả.
- Server từ chối token nếu chữ ký không hợp lệ, hết hạn, chưa có hiệu lực, sai issuer, sai audience hoặc không đáp ứng chính sách truy cập.

JWT được ứng dụng trong những trường hợp nào?
Nhờ khả năng xác thực nhanh, không cần lưu trạng thái và dễ tích hợp với nhiều nền tảng, JWT được sử dụng trong nhiều hệ thống hiện đại. Dưới đây là những ứng dụng phổ biến nhất.
- Xác thực người dùng: JWT được gửi kèm mỗi request để xác minh danh tính người dùng.
- Phân quyền truy cập: Dựa vào role hoặc permissions trong Payload để kiểm soát quyền sử dụng tài nguyên.
- Kết nối API và Microservices: Các dịch vụ có thể tự kiểm tra JWT bằng Secret Key hoặc Public Key mà không cần truy vấn lại hệ thống xác thực.
- Single Sign-On (SSO): Hỗ trợ người dùng đăng nhập một lần và truy cập nhiều ứng dụng thông qua các giao thức như OpenID Connect.
- Trao đổi thông tin: Truyền dữ liệu giữa các hệ thống dưới dạng token có chữ ký, giúp kiểm tra tính toàn vẹn của thông tin.

Các điểm hạn chế của JWT
Mặc dù có nhiều ưu điểm, JWT không phải lúc nào cũng là lựa chọn tối ưu. Khi triển khai, bạn cần lưu ý một số hạn chế sau:
- Khó thu hồi token trước khi hết hạn: Sau khi được phát hành, JWT vẫn có hiệu lực cho đến khi hết thời gian sống. Nếu người dùng đăng xuất hoặc tài khoản bị khóa, máy chủ không thể hủy token ngay lập tức nếu không triển khai thêm cơ chế hỗ trợ.
- Token có thể lớn hơn Session ID: JWT chứa Header, Payload và Signature nên kích thước thường lớn hơn Session ID truyền thống. Điều này có thể làm tăng dung lượng dữ liệu trong mỗi yêu cầu HTTP.
- Payload có thể đọc được nếu JWT chỉ được ký: Dữ liệu trong Payload được biểu diễn bằng Base64url, không phải mã hóa bảo mật. Với token chỉ được ký, nội dung Payload vẫn có thể đọc được. Vì vậy, bất kỳ ai cũng có thể giải mã để xem thông tin bên trong. JWT chỉ đảm bảo tính toàn vẹn của dữ liệu, không đảm bảo tính bí mật.
- Rủi ro bảo mật nếu quản lý khóa hoặc thời hạn không đúng: Nếu Secret Key bị lộ, thời gian hết hạn quá dài hoặc token được lưu ở vị trí không an toàn, kẻ tấn công có thể lợi dụng JWT để truy cập trái phép vào hệ thống.
JWT và Session khác nhau như thế nào?
JWT và Session đều được sử dụng để xác thực người dùng sau khi đăng nhập. Tuy nhiên, hai cơ chế này có nhiều điểm khác biệt về cách lưu trữ thông tin, khả năng mở rộng và mức độ quản lý phiên làm việc.
| Tiêu chí | Session-based Authentication | JWT (Token-based Authentication) |
| Nơi lưu trữ trạng thái | Stateful: Lưu trên bộ nhớ RAM/Database của Server. | Stateless: Lưu ở phía Client (LocalStorage, Cookie). |
| Khả năng mở rộng (Scalability) | Khó mở rộng khi scale nhiều Server (cần Dải Redis/Memcached chung). | JWT thuận lợi cho một số hệ thống phân tán, trong khi Session cũng có thể mở rộng bằng kho lưu phiên tập trung. |
| Kích thước dữ liệu | Rất nhỏ (chỉ chứa một chuỗi Session ID). | Tương đối lớn hơn (chứa Header, Payload và Chữ ký). |
| Đăng xuất / Hủy truy cập | Dễ dàng (Server chỉ cần xóa Session trong DB). | Có thể thu hồi bằng denylist, token version, trạng thái tài khoản, mốc đổi mật khẩu hoặc cơ chế thu hồi refresh token. |
| Phù hợp với | Website truyền thống (Monolithic HTML render). | Lựa chọn JWT hay Session phụ thuộc kiến trúc, yêu cầu thu hồi, mô hình bảo mật và cách quản lý danh tính. |
Giải đáp các thắc mắc thường gặp về JWT
Token bị đánh cắp thì sao?
Đây là rủi ro lớn nhất của mô hình Stateless. Để giảm thiểu rủi ro, hệ thống thường kết hợp sử dụng bộ đôi:
- Access Token: Access token nên có thời hạn ngắn, được xác định theo mức độ rủi ro và trải nghiệm người dùng của hệ thống, dùng để gọi API. Nếu bị mất, khoảng thời gian kẻ xấu có thể lợi dụng là ngắn.
- Refresh Token: Có thời gian sống dài hơn (vài ngày/tuần), dùng để xin cấp Access Token mới. Refresh token cần được lưu trữ an toàn, hỗ trợ rotation và có khả năng thu hồi khi phát hiện bất thường.
Có nên lưu mật khẩu vào JWT không?
Tuyệt đối KHÔNG. Mọi thông tin trong phần Payload chỉ được mã hóa dạng Base64, bất kỳ ai chặn được Token cũng có thể đọc sạch nội dung. Bạn chỉ nên lưu các thông tin công khai như user_id, username, role hoặc thời điểm hết hạn.
Nên lưu JWT ở đâu trên Client?
- LocalStorage: Token trong LocalStorage không tự động được gửi kèm request, nhưng có thể bị đánh cắp nếu JavaScript độc hại chạy trên trang.
- Cookie (Thuộc tính HttpOnly & SameSite): Khuyên dùng. HttpOnly ngăn JavaScript đọc trực tiếp cookie, nhưng ứng dụng vẫn phải phòng chống XSS và CSRF bằng các biện pháp riêng. Để phòng chống lỗi CSRF, bạn chỉ cần cấu hình thuộc tính SameSite=Strict/Lax hoặc kèm theo CSRF Token.
Có thể thu hồi JWT trước khi hết hạn không?
Có thể, nhưng bạn sẽ mất đi một phần tính chất Stateless thuần túy. Để thu hồi JWT (khi người dùng đăng xuất hoặc đổi mật khẩu), bạn có thể áp dụng giải pháp Blacklist (Danh sách đen) hoặc Revocation List bằng cách lưu danh sách các Token bị hủy vào Redis/In-memory DB và kiểm tra nó mỗi khi tiếp nhận request.
Kết luận
JWT (JSON Web Token) là một tiêu chuẩn phổ biến để xác thực và trao đổi thông tin giữa các hệ thống hiện đại. Với cấu trúc gồm Header, Payload và Signature, JWT giúp hệ thống truyền và xác minh claims sau khi token được phát hành bởi một bên đáng tin cậy và được kiểm tra đúng cách.
Tuy nhiên, JWT chỉ thực sự an toàn khi được triển khai đúng cách. Việc thiết lập thời gian hết hạn hợp lý, bảo vệ khóa ký, sử dụng HTTPS, kết hợp Access Token với Refresh Token và lựa chọn phương thức lưu trữ phù hợp sẽ giúp giảm thiểu các rủi ro bảo mật trong quá trình vận hành.

Nếu doanh nghiệp đang xây dựng các ứng dụng AI, API hoặc hệ thống xác thực hiện đại, FPT.AI cung cấp nền tảng và giải pháp giúp tích hợp, quản lý và triển khai AI an toàn, hiệu quả. Liên hệ 1900 638 399 để được đội ngũ FPT.AI tư vấn giải pháp phù hợp với nhu cầu của doanh nghiệp.
>>> Đọc thêm: API Authentication là gì? Các phương thức xác thực API phổ biến
Nội dung bài viết được tổng hợp, đối chiếu và cập nhật từ các tài liệu chính thức, công trình nghiên cứu và nguồn thông tin uy tín trong lĩnh vực Trí tuệ nhân tạo, Máy học và Khoa học dữ liệu.
Nguồn tham khảo:
[1] JWT.io. “Introduction to JSON Web Tokens.” https://www.jwt.io/introduction
[2] Wikipedia. “JSON Web Token.” https://en.wikipedia.org/wiki/JSON_Web_Token
[3] GeeksforGeeks. “JSON Web Token (JWT).” https://www.geeksforgeeks.org/web-tech/json-web-token-jwt/