[2026] JWT là gì? Giải mã JSON Web Token chi tiết từ A-Z

JWT là một chuẩn xác thực phổ biến giúp truyền tải thông tin an toàn giữa các hệ thống thông qua chuỗi token được mã hóa. Hiện nay, JWT được ứng dụng rộng rãi trong API, website, mobile app và các hệ thống đăng nhập hiện đại nhờ khả năng xác thực nhanh, gọn và dễ tích hợp. Trong bài viết này, hãy cùng Vinahost tìm hiểu cấu trúc hoạt động, ưu nhược điểm cùng những lưu ý quan trọng khi ứng dụng JWT vào thực tế.

1. JWT là gì?

JWT (JSON Web Token) là một tiêu chuẩn mở được định nghĩa trong RFC 7519, dùng để tạo các token truy cập an toàn dựa trên định dạng JSON. Công nghệ này cung cấp một phương thức nhỏ gọn, độc lập để truyền tải thông tin giữa các bên một cách an toàn, thường được sử dụng trong quá trình xác thực (authentication) và phân quyền (authorization) trên các ứng dụng web và di động hiện đại.

Dữ liệu trong JWT được biểu diễn dưới dạng đối tượng JSON (JSON object) và được ký số nhằm đảm bảo tính xác thực cũng như tính toàn vẹn trong quá trình trao đổi dữ liệu giữa client và server. JWT có các thành phần chính là:

• Header
  • Chứa thông tin về loại token (JWT)
  • Chứa thuật toán ký được sử dụng (ví dụ: HMAC, RSA, ECDSA)

• Payload
  • Chứa các “claims” (tuyên bố)
  • Bao gồm thông tin như: dữ liệu người dùng, vai trò, quyền truy cập,…

• Signature
  • Được tạo bằng cách mã hóa Header và Payload
  • Dùng để xác minh tính toàn vẹn của token
  • Giúp đảm bảo token không bị thay đổi trong quá trình truyền tải

2. JWT được dùng để làm gì?

JSON Web Token (JWT) được ứng dụng rộng rãi trong các kiến trúc phần mềm hiện đại nhờ tối ưu hóa cho hai tác vụ cốt lõi: Phân quyền (Authorization) dựa trên cơ chế Stateless không lưu phiên trên server và Trao đổi dữ liệu an toàn (Information Exchange) thông qua chữ ký số được chuẩn hóa theo RFC 7519. Cụ thể, các kịch bản triển khai thực tế bao gồm:

• Phân quyền (Authorization):
  • Đây là trường hợp sử dụng phổ biến nhất của JSON Web Token
  • Sau khi người dùng đăng nhập thành công, mỗi request tiếp theo sẽ kèm theo JSON Web Token
  • JWT giúp xác định quyền truy cập vào các routes, dịch vụ và tài nguyên tương ứng
  • Được sử dụng rộng rãi trong Single Sign-On (SSO)
  • Ưu điểm: gọn nhẹ, hiệu suất cao, dễ triển khai trên nhiều tên miền

• Trao đổi thông tin (Information Exchange):
  • JWT được dùng để truyền tải dữ liệu an toàn giữa các bên
  • Sử dụng cơ chế ký số bằng cặp khóa công khai/riêng tư để xác minh người gửi
  • Chữ ký (Signature) được tạo từ header và payload
  • Đảm bảo nội dung không bị chỉnh sửa trong quá trình truyền đi
  • Có thể xác thực danh tính người gửi nhờ cơ chế ký số

3. Cấu trúc của JSON Web Token

Một JSON Web Token tiêu chuẩn bao gồm 3 phần chính được phân tách với nhau bằng dấu chấm (.), gồm: Header, Payload và Signature. Mỗi thành phần đều được mã hóa bằng chuẩn Base64Url để thuận tiện cho việc truyền tải dữ liệu qua mạng.

• Header: Chứa thông tin về loại token và thuật toán dùng để ký
• Payload: Chứa dữ liệu hoặc các claims như thông tin người dùng, quyền truy cập,…
• Signature: Chữ ký dùng để xác thực tính hợp lệ và đảm bảo token không bị chỉnh sửa

3.1. Header – Siêu dữ liệu thuật toán

Header chứa các metadata liên quan đến JWT, bao gồm loại token và thuật toán được sử dụng để ký hoặc mã hóa token. Thành phần này thường lưu thông tin về thuật toán chính (alg) dùng để ký/xác thực, loại token (typ) và đôi khi có thêm kiểu nội dung (cty).

3.2. Payload – Tập hợp các Claims

Payload chứa các claims (tuyên bố) về người dùng và những dữ liệu liên quan khác. Theo chuẩn RFC 7519, Payload thực tế được chia làm 3 loại chính: 

• Registered Claims (Claims tiêu chuẩn):

Là các claims được định nghĩa sẵn theo chuẩn JWT, bao gồm:

• • iss (Issuer): đơn vị phát hành token
  • sub (Subject): đối tượng của token
  • exp (Expiration Time): thời gian hết hạn
  • nbf (Not Before): thời điểm token bắt đầu có hiệu lực
  • iat (Issued At): thời gian phát hành token
  • jti (JWT ID): mã định danh duy nhất của JSON Web Token
• Public Claims (Claims công khai): Là các claims do người dùng tự định nghĩa để phục vụ nhu cầu riêng, nhưng cần được thống nhất giữa các hệ thống sử dụng JSON Web Token nhằm tránh xung đột với các claims tiêu chuẩn.

• Private Claims (Claims riêng tư): Là các claims tùy chỉnh dùng để truyền tải thông tin giữa các bên đã thỏa thuận trước và không nằm trong chuẩn JWT.

3.3. Signature – Chữ ký xác thực toàn vẹn

Signature trong JWT được tạo bằng các thuật toán như HS256 (HMAC + SHA-256) theo chuẩn JWA. Đây là hàm băm một chiều nên không thể giải mã ngược để lấy dữ liệu gốc.

Quy trình xác thực Signature phụ thuộc vào thuật toán: Với khóa đối xứng (HS256), server sử dụng secret key để tái tạo lại signature và đối chiếu. Với khóa bất đối xứng (RS256), server sử dụng Public Key để giải mã và kiểm tra tính hợp lệ toán học của chữ ký phát hành từ Private Key. Quy trình xác thực bằng JSON Web Token thường bao gồm 5 bước chính:

• Bước 1: Máy khách (Client) gửi yêu cầu đăng nhập: Người dùng nhập thông tin đăng nhập và gửi request đến server.
• Bước 2: Máy chủ xác thực thông tin và cấp phát JWT: Máy chủ kiểm tra thông tin tài khoản. Nếu hợp lệ, server sẽ tạo và trả về một JWT cho client.
• Bước 3: Client lưu trữ token: JSON Web Token có thể được lưu trong Local Storage, Session Storage hoặc Cookie tùy theo cơ chế triển khai.
• Bước 4: Client đính kèm token vào Header (Authorization: Bearer <token>) ở các request tiếp theo: Ở những request sau, client sẽ đính kèm token vào Header theo định dạng: Authorization: Bearer <token>
• Bước 5: Máy chủ xác thực chữ ký và thời hạn trước khi cấp quyền truy cập: Máy chủ sẽ kiểm tra Signature và thời hạn của JWT trước khi cấp quyền truy cập vào API hoặc tài nguyên tương ứng.

3.4. Luồng hoạt động của Access Token và Refresh Token

JSON Web Token không nên có thời gian sống quá dài vì nếu token bị đánh cắp, kẻ tấn công có thể sử dụng nó để truy cập hệ thống trong suốt thời gian token còn hiệu lực. Điều này làm tăng nguy cơ mất quyền kiểm soát tài khoản và rò rỉ dữ liệu.

Để khắc phục vấn đề này, hệ thống thường sử dụng kết hợp:

• Access Token: Có thời gian sống ngắn, dùng để xác thực và truy cập API.

• Refresh Token: Có thời gian sống dài hơn, được lưu trữ ở nơi an toàn và dùng để cấp lại Access Token mới khi token cũ hết hạn mà không cần người dùng đăng nhập lại.

4. Ưu điểm và nhược điểm của JWT

JSON Web Token mang lại nhiều lợi ích như hiệu suất cao, khả năng mở rộng tốt và dễ tích hợp trong các hệ thống hiện đại. Tuy nhiên, công nghệ này cũng tồn tại một số hạn chế liên quan đến bảo mật và quản lý token.

Dưới đây là bảng tổng hợp những ưu điểm và nhược điểm nổi bật của JWT.

Mặc dù sở hữu nhiều ưu điểm vượt trội, nhược điểm lớn nhất của JWT vẫn là tính chất khó thu hồi trước thời điểm hết hạn (exp). Để khắc phục điểm hạn chế này mà không làm mất đi tính stateless của hệ thống, các nhà phát triển thường sử dụng Redis Blacklist kết hợp với Claim tiêu chuẩn jti (JWT ID).

1. Khởi tạo jti: Khi tạo JWT, Auth Server bắt buộc phải sinh một chuỗi ngẫu nhiên, duy nhất gán vào claim jti (ví dụ: “jti”: “a1b2c3d4-e5f6…”) bên cạnh thời gian hết hạn exp.
2. Kịch bản Đăng xuất / Thu hồi: Khi người dùng yêu cầu đăng xuất, Client gửi token hiện tại lên API logout. Backend sẽ thực hiện:
   • Trích xuất jti và exp từ token.
   • Tính toán thời gian sống còn lại của token: TTL = exp – CurrentTime.
   • Ghi một bản ghi vào Redis với Key là blacklist:<jti> và giá trị tùy ý, thiết lập thời gian tự động xóa (TTL) đúng bằng khoảng thời gian TTL vừa tính toán.
3. Kịch bản Xác thực (Middleware): Tại mỗi Request gửi lên hệ thống, trước khi xử lý logic nghiệp vụ, Middleware xác thực sẽ kiểm tra nhanh trong Redis xem jti của token đó có tồn tại trong danh sách đen hay không.
   • Nếu Có : Trả về mã lỗi 401 Unauthorized (Token đã bị hủy).
   • Nếu Không : Tiếp tục xử lý request bình luận hoặc truy cập.

Giải pháp này duy trì tính tối giản của hệ thống. Redis tự động dọn dẹp các jti đã hết hạn thực tế nhờ cơ chế TTL sinh sẵn, giúp dung lượng bộ nhớ lưu trữ Blacklist luôn được kiểm soát ở mức tối thiểu mà không cần can thiệp thủ công.

5. So sánh JWT với Session, Opaque Token và PASETO

Mỗi cơ chế xác thực như JSON Web Token, Session, Opaque Token hay PASETO đều có cách hoạt động, mức độ bảo mật và phạm vi ứng dụng khác nhau. Việc hiểu rõ ưu nhược điểm của từng giải pháp sẽ giúp lựa chọn phương thức phù hợp với nhu cầu triển khai hệ thống.

Dưới đây là bảng so sánh chi tiết giữa JWT và các cơ chế xác thực phổ biến hiện nay.

JSON Web Token dần trở thành lựa chọn phổ biến thay cho Session nhờ:

• Hỗ trợ tốt cho CORS (Cross-Origin Resource Sharing): Cookie/Session thường gặp khó khăn khi gọi API giữa nhiều domain khác nhau, trong khi JWT được gửi qua HTTP Header nên dễ dàng hoạt động trong môi trường cross-domain.
• Khả năng mở rộng cao (Scalability): Session yêu cầu server lưu trạng thái người dùng, gây tốn tài nguyên và phức tạp khi triển khai Load Balancer. JWT hoạt động theo cơ chế stateless nên server chỉ cần secret key để xác thực token, giúp hệ thống dễ scale trên nhiều server.
• Thân thiện với ứng dụng mobile: Ứng dụng iOS/Android quản lý token đơn giản và ổn định hơn so với việc xử lý Cookie/Session của trình duyệt, giúp JWT phù hợp với mobile app và API hiện đại.

6. Top 6 lỗ hổng JWT phổ biến nhất 2026 và cách phòng chống

JSON Web Token giúp tối ưu xác thực và phân quyền trong các hệ thống hiện đại, nhưng nếu cấu hình sai hoặc triển khai thiếu an toàn, token có thể trở thành mục tiêu khai thác của hacker. Dưới đây là 6 lỗ hổng JWT phổ biến và nguy hiểm nhất hiện nay mà lập trình viên và quản trị hệ thống cần đặc biệt lưu ý.

6.1. Các lỗ hổng JWT Critical

Sai lầm trong cấu hình thư viện và quản lý khóa bí mật (Secret Key) là nguyên nhân chính khiến JWT bị khai thác, dẫn đến các lỗ hổng nghiêm trọng như bypass chữ ký hoặc chiếm quyền quản trị. Dưới đây là phân tích chi tiết 6 lỗ hổng JWT nghiêm trọng nhất kèm theo phương án vá lỗi tương ứng:

6.2. CVE thực tế 2025 cần vá ngay

Bên cạnh các lỗ hổng cấu hình phổ biến, nhiều thư viện và thành phần xử lý JSON Web Token trong năm 2025 cũng đã xuất hiện các CVE nghiêm trọng ảnh hưởng trực tiếp đến bảo mật hệ thống. Việc cập nhật phiên bản và vá lỗi kịp thời là rất cần thiết để tránh nguy cơ bị khai thác hoặc chiếm quyền truy cập trái phép.

6.3. Checklist 10 hành động cần thực hiện ngay để bảo mật JWT

Để giảm thiểu rủi ro bị giả mạo, đánh cắp hoặc khai thác JWT, doanh nghiệp và lập trình viên cần áp dụng đồng thời nhiều biện pháp bảo mật trong quá trình triển khai. Dưới đây là checklist những hành động quan trọng nên thực hiện ngay để tăng cường mức độ an toàn cho hệ thống sử dụng JWT.

1. Khuyến nghị sử dụng RS256 hoặc ES256 cho các hệ thống phân tán (như SSO) để tránh chia sẻ khóa bí mật. HS256 vẫn phù hợp cho hệ thống khép kín nếu khóa bí mật được bảo vệ tốt.
2. Khởi tạo khóa bí mật ngẫu nhiên tối thiểu 256-bit (32 ký tự) và luân chuyển khóa định kỳ (khoảng 90 ngày).
3. Thiết lập Access Token có vòng đời ngắn (khoảng 15 phút) kết hợp Refresh Token dài hạn (khoảng 7 ngày).
4. Lưu trữ token trong Cookie với cờ HttpOnly, Secure và SameSite=Strict; tuyệt đối không lưu trong localStorage.
5. Xác thực đầy đủ các tham số quan trọng như: iss, aud, exp, nbf, jti.
6. Thiết lập whitelist thuật toán và từ chối hoàn toàn token có Header alg: none.
7. Triển khai endpoint JWKS qua kết nối TLS để phân phối khóa công khai an toàn.
8. Áp dụng cơ chế luân chuyển (Token Rotation) để cấp mã mới sau mỗi lần refresh token.
9. Triển khai hệ thống giám sát và phát hiện bất thường dựa trên IP, vị trí hoặc Device Fingerprint.
10. Triển khai giải pháp WAAP (Web Application & API Protection) để ngăn chặn các hành vi can thiệp và giả mạo hoặc can thiệp JWT.

const express = require('express');
const jwt = require('jsonwebtoken');
const fs = require('fs');
const path = require('path');

const app = express();

// Đọc Public Key từ file hệ thống để xác thực chữ ký (Không cần giữ Private Key ở đây)
const publicKey = fs.readFileSync(path.join(__dirname, 'public.pem'), 'utf8');

function authenticateRS256(req, res, next) {
const authHeader = req.headers['authorization'];
// Trích xuất chuỗi token từ Header định dạng "Bearer <token>"
const token = authHeader && authHeader.split(' ')[1];

if (!token) {
return res.status(401).json({ error: 'Access token is missing' });
}

// Chỉ cho phép giải mã bằng thuật toán RS256 để tránh Algorithm Confusion Attack
jwt.verify(token, publicKey, { algorithms: ['RS256'] }, (err, decodedPayload) => {
if (err) {
return res.status(403).json({ error: 'Invalid or expired token' });
}

// Gán dữ liệu người dùng đã giải mã vào đối tượng request để các controller phía sau sử dụng
req.user = decodedPayload;
next();
});
}

// Route được bảo vệ
app.get('/api/secure-data', authenticateRS256, (req, res) => {
res.json({ message: 'Access granted', user: req.user });
});

// Giả định cơ sở dữ liệu lưu trữ Refresh Token hợp lệ và các token đã bị hủy
const activeRefreshTokens = new Set();
const usedRefreshTokens = new Set(); // Blacklist lưu trữ các Refresh Token đã qua sử dụng

function handleTokenRotation(req, res) {
const { refreshToken } = req.body;

if (!refreshToken) {
return res.status(400).json({ error: 'Refresh token is required' });
}

// KỊCH BẢN BẢO MẬT: Phát hiện tấn công giả mạo do kẻ gian sử dụng lại Refresh Token cũ
if (usedRefreshTokens.has(refreshToken)) {
// Thu hồi toàn bộ phiên đăng nhập của User liên quan đến token này để đảm bảo an toàn
activeRefreshTokens.clear(); // Trong thực tế, truy vấn DB xóa toàn bộ session của User ID này
return res.status(403).json({
error: 'Security Alert: This refresh token has already been used. All sessions revoked.'
});
}

if (!activeRefreshTokens.has(refreshToken)) {
return res.status(403).json({ error: 'Invalid refresh token' });
}

// Xác thực token hợp lệ
jwt.verify(refreshToken, process.env.REFRESH_TOKEN_SECRET, (err, user) => {
if (err) return res.status(403).json({ error: 'Expired or invalid token' });

// Tiến hành quay vòng khóa (Rotation)
activeRefreshTokens.delete(refreshToken);
usedRefreshTokens.add(refreshToken); // Đưa token cũ vào danh sách đã sử dụng

// Tạo cặp Token mới
const newAccessToken = jwt.sign({ userId: user.userId }, process.env.ACCESS_TOKEN_SECRET, { expiresIn: '15m' });
const newRefreshToken = jwt.sign({ userId: user.userId }, process.env.REFRESH_TOKEN_SECRET, { expiresIn: '7d' });

// Lưu trữ Refresh Token mới vào DB
activeRefreshTokens.add(newRefreshToken);

// Trả về cho Client
res.json({
accessToken: newAccessToken,
refreshToken: newRefreshToken
});
});
}

JSON Web Token (JWT) phù hợp với các hệ thống cần xác thực nhanh, khả năng mở rộng cao và giao tiếp giữa nhiều ứng dụng hoặc dịch vụ khác nhau.

Dưới đây là những trường hợp sử dụng JWT phổ biến nhất:

• Xác thực người dùng (Authentication): JSON Web Token thường được dùng sau khi người dùng đăng nhập thành công. Server sẽ tạo token và gửi về client, sau đó client sử dụng token này trong các request tiếp theo để xác minh danh tính mà không cần đăng nhập lại nhiều lần.
• Single Sign-On – SSO: JSON Web Token rất phù hợp cho cơ chế đăng nhập một lần (SSO), cho phép người dùng truy cập nhiều hệ thống hoặc dịch vụ liên quan chỉ với một lần xác thực. Điều này đặc biệt hữu ích trong các hệ sinh thái lớn hoặc doanh nghiệp có nhiều ứng dụng nội bộ.
• Phân quyền truy cập (Authorization): JSON Web Token có thể lưu thông tin về vai trò (role), quyền hạn hoặc phạm vi truy cập của người dùng trong payload. Server sẽ dựa vào các claims này để quyết định người dùng được phép truy cập API, chức năng hoặc tài nguyên nào.
• Bảo vệ và xác thực API: JSON Web Token được sử dụng rộng rãi trong RESTful API và GraphQL API nhằm xác thực các request giữa client và server. Các ứng dụng frontend, mobile app hoặc microservices có thể gửi JWT qua HTTP Header để truy cập API an toàn.
• Kiến trúc Microservices: Trong hệ thống microservices, JWT giúp các service xác thực lẫn nhau mà không cần lưu session tập trung. Điều này giúp giảm tải cho hệ thống xác thực trung tâm và cải thiện khả năng mở rộng.
• Ứng dụng mobile (iOS/Android): JSON Web Tokenphù hợp với mobile app vì token có thể dễ dàng lưu trữ và gửi kèm trong các request API mà không phụ thuộc vào cơ chế cookie của trình duyệt.
• Hệ thống đa domain hoặc cross-domain: JSON Web Tokenhoạt động tốt trong môi trường CORS (Cross-Origin Resource Sharing), nơi frontend và backend nằm trên các domain khác nhau. Vì token được gửi qua Header nên không gặp nhiều hạn chế như Cookie/Session truyền thống.
• Trao đổi thông tin an toàn: JSON Web Tokencó thể được sử dụng để truyền dữ liệu xác thực hoặc thông tin giữa các hệ thống. Nhờ cơ chế ký số, bên nhận có thể xác minh nguồn gốc và đảm bảo nội dung không bị thay đổi trong quá trình truyền tải.
• Hệ thống cần khả năng mở rộng cao (Scalability): JSON Web Token hoạt động theo mô hình stateless nên server không cần lưu session của người dùng. Điều này giúp dễ dàng mở rộng hệ thống trên nhiều server hoặc môi trường cloud.

Mặc dù JWT mang lại nhiều lợi ích về hiệu suất và khả năng mở rộng, nhưng không phải hệ thống nào cũng phù hợp để triển khai công nghệ này. Trong một số trường hợp, việc sử dụng JWT có thể làm tăng rủi ro bảo mật hoặc gây khó khăn trong quản lý phiên đăng nhập.

• Khi cần thu hồi token ngay lập tức trước thời gian hết hạn.
• Khi hệ thống yêu cầu kiểm soát phiên đăng nhập chặt chẽ.
• Khi ứng dụng chỉ chạy trên một server và Session đã đủ đáp ứng.
• Khi payload chứa nhiều dữ liệu làm tăng kích thước token.
• Khi không muốn client đọc được dữ liệu trong payload JWT.

Kết luận

Qua bài viết trên, hy vọng bạn đã hiểu rõ JWT là gì, cách hoạt động của JSON Web Token cũng như những ưu điểm, hạn chế và rủi ro bảo mật cần lưu ý khi triển khai. JWT hiện đang được sử dụng rộng rãi trong các hệ thống web, API và ứng dụng hiện đại nhờ khả năng xác thực linh hoạt, hiệu suất cao và dễ mở rộng.

Nếu bạn cần tư vấn giải pháp bảo mật API, xác thực người dùng hoặc triển khai hệ thống an toàn với JWT, hãy liên hệ Vinahost để được tư vấn và hỗ trợ. Ngoài ra, bạn cũng có thể xem thêm tại đây để cập nhật thêm nhiều kiến thức hữu ích.

• Email: cskh@vinahost.vn
• Hotline: 1900 6046 phím 1
• Livechat: https://livechat.vinahost.vn/chat.php