Trong thế giới web hiện đại—SPA, microservices, mobile, cloud—bạn sẽ thường nghe: “Dùng JWT đi cho tiện.”
Nhưng JWT thực sự là gì? Hoạt động ra sao? Tại sao lại phổ biến đến vậy?
Bài viết này sẽ giúp bạn hiểu JWT từ A → Z theo cách đơn giản nhất!
🌐 1. JWT Là Gì?
JWT (JSON Web Token) là một chuỗi ký tự dài dùng để xác thực người dùng giữa client và server.
Bạn có thể tưởng tượng JWT như một chiếc "thẻ căn cước":
- Server cấp thẻ sau khi bạn đăng nhập thành công.
- Trong thẻ có thông tin xác nhận bạn là ai.
- Khi muốn làm điều gì trên hệ thống, chỉ cần đưa thẻ này.
Điểm đặc biệt:
👉 JWT KHÔNG lưu trên server, nó tự chứa đầy đủ thông tin xác thực và "chứng minh thư".
Ví dụ một JWT điển hình:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJ1c2VySWQiOiIxMjMiLCJyb2xlIjoiYWRtaW4ifQ
.XlAaCByK8P5X3eK0XJ_kHzdYVxVdzH-LA4Q4zS9xk3kMặc dù nhìn dài dòng, JWT chỉ có 3 phần nối với nhau bằng dấu chấm.
🔍 2. Ba Thành Phần Của JWT Hoạt Động Như Thế Nào?
Một JWT luôn có dạng:
Header.Payload.Signature
✔ 1. Header
Chứa thông tin giải mã token bằng cách nào (thuật toán ký):
{
"alg": "HS256",
"typ": "JWT"
}- `alg`: thuật toán ký (vd: HS256, RS256)
- `typ`: loại token (luôn là JWT)
✔ 2. Payload
Chứa dữ liệu mà server muốn gửi cho client, ví dụ:
{
"userId": 123,
"role": "admin",
"exp": 1712345678
}Ba loại thông tin thường gặp:
- **Standard Claims** (chuẩn):
- `exp`: thời gian hết hạn
- `iat`: thời điểm tạo
- `sub`: token thuộc về ai
- **Custom Claims** (tuỳ chỉnh):
- `userId`, `role`, `email`, `permissions`...
- **Lưu ý:** *Payload KHÔNG mã hoá!* Ai cũng đọc được, nhưng KHÔNG ai chỉnh sửa được nhờ phần chữ ký.
✔ 3. Signature (Chữ Ký)
Đảm bảo KHÔNG ai thay đổi token.
Cách tạo signature:
signature = HMACSHA256(
base64(header) + "." + base64(payload),
secret_key
)Nếu ai đó sửa payload, signature sẽ không hợp lệ nữa.
🔄 3. JWT Hoạt Động Như Thế Nào? (Flow Cơ Bản)
Bước 1: User đăng nhập (gửi username/password cho server).
Bước 2: Server xác thực và trả về JWT, chứa thông tin như userId, role, exp.
Bước 3: Client lưu JWT (có thể ở localStorage, sessionStorage hoặc cookie).
Bước 4: Client gửi JWT lên server kèm mỗi request API:
Authorization: Bearer <jwt-token>Bước 5: Server kiểm tra token:
- Giải mã, check signature, lấy user info.
- Nếu hợp lệ → trả về dữ liệu.
- Nếu sai hoặc hết hạn → trả về 401 Unauthorized.
Ưu điểm: KHÔNG cần query database mỗi lần → cực nhanh.
🌟 4. Tại Sao JWT Phổ Biến?
- **Stateless** – Không lưu session trên server → ít tốn RAM, cực “hợp gu” microservices, cloud.
- **Tốc độ cao** – Server chỉ cần verify chữ ký, không truy vấn DB liên tục.
- **Truyền được giữa các service** – API Gateway, microservice nào cũng hiểu JWT.
- **Chuẩn mở, đa ngôn ngữ** – Được hỗ trợ bởi Java, Node.js, Python, Go, .Net, PHP...
- **Quá hợp cho SPA / mobile app** – React, Angular, Vue, iOS, Android.
⚖️ 5. So Sánh: JWT, Session Cookie, OAuth2 Token
| Tiêu chí | JWT | Session Cookie | OAuth2 Token |
|--------------------|-----------------|------------------|---------------|
| Lưu trên server | ❌ KHÔNG | ✔ CÓ | ❌ KHÔNG |
| Kiến trúc phù hợp | SPA, Mobile, Micro | Web truyền thống | Hệ thống lớn, SSO |
| Dễ scale | ✔ | ❌ | ✔ |
| Logout tức thì | Khó | ✔ | Có cơ chế |
| Bảo mật CSRF | Tốt (header) | Rủi ro (cookie) | Tốt |
| Tự chứa thông tin | ✔ | ❌ | ✔ |
| Cách verify | Check chữ ký | Check session DB | Check chữ ký |
| Mức độ phức tạp | Trung bình | Dễ | Cao |
🎯 Khi Nào Dùng Cái Nào?
- **Session Cookie:**
- Web truyền thống (Laravel, Rails, Spring MVC)
- Muốn logout mất hiệu lực ngay
- **JWT:**
- SPA (React/Angular/Vue), Mobile App, Microservices, API Gateway, Serverless
- **OAuth2/OIDC:**
- Login Google/Facebook, SSO, hệ thống lớn, cần phân quyền theo scopes (read, write...)
🧠 Tóm Tắt Ngắn Gọn
| Công nghệ | Điểm mạnh | Khi nên dùng |
|-------------------|---------------------------|------------------------|
| Session Cookie | Dễ, an toàn, logout nhanh | Web truyền thống |
| JWT | Nhanh, stateless, scale tốt | SPA, API, mobile, microservices |
| OAuth2 Token | Chuẩn hóa – SSO, enterprise| Login Google, SSO, hệ lớn |
🔃 Luồng JWT Chuẩn (Diagram ASCII)
+-------------+ 1. Login +-------------------+
| Client | ---------------------> | Auth Server |
+-------------+ (username/password) +-------------------+
|
| 2. Xác thực
v
+-------------------+
| Generate JWT |
| - Access Token |
| - Refresh Token |
+-------------------+
|
3. Trả về token |
+-------------+ <----------------------------+
| Client |
+-------------+
| 4. Lưu token (localStorage, cookie)
| 5. Gọi API với Access Token:
| Authorization: Bearer <AccessToken>
|
| 6. Server xác thực Access Token:
| Nếu valid -> trả về data
| Nếu hết hạn -> dùng Refresh Token (cookie)
v
(Quy trình renew token tương tự như trên)🎯 Sự Khác Biệt Giữa Access Token & Refresh Token
| Tiêu chí | Access Token | Refresh Token |
|-----------------|--------------------|------------------------------|
| Mục đích | Gọi API | Lấy Access Token mới |
| Sống | Rất ngắn (5–15 phút) | Dài (7–30 ngày, có thể hơn) |
| Lưu trữ | localStorage/memory | httpOnly cookie (chống XSS) |
| Gửi qua API | Authorization: Bearer| Chỉ dùng khi renew |
| Bảo mật | Ít an toàn hơn | An toàn hơn (dùng httpOnly) |
| Nguy cơ | Bị lộ, hacker dùng ngay| Nếu bị lộ, nguy hiểm hơn do sống lâu |
| Cơ chế sử dụng | EVERY API request | Chỉ dùng khi Access Token hết hạn |
| Có liên quan session server? | Stateless | Có (nếu dùng rotation) |
📌 Tại Sao Cần 2 Loại Token?
- **Access Token ngắn**: Nếu bị lộ, hacker chỉ dùng được vài phút.
- **Refresh Token giúp không phải đăng nhập lại** liên tục.
- **Refresh Token có thể bảo vệ tốt hơn** với httpOnly cookie và rotation.
🔁 Flow Refresh Token Rotation (Chuẩn Doanh Nghiệp)
1. Client gửi Refresh Token.
2. Server trả về:
- Access Token mới
- Refresh Token mới (=> token cũ lập tức vô hiệu hóa trong DB)
3. Nếu token cũ bị lộ => hacker không thể dùng.
📘 Tóm Tắt Nhanh Nhất
| Câu hỏi | Trả lời |
|-------------------------------------|-------------------------------------------|
| Vì sao cần 2 loại token? | Bảo mật, không phải login liên tục |
| Access Token dùng để làm gì? | Gọi API |
| Refresh Token dùng để làm gì? | Lấy Access Token mới khi hết hạn |
| Access Token sống bao lâu? | 5–15 phút |
| Refresh Token sống bao lâu? | 7–30 ngày |
| Bảo mật Refresh Token thế nào? | httpOnly cookie, chỉ gửi qua HTTPS |
🔐 Nhớ Kỹ Khi Dùng JWT
- Không lưu data nhạy cảm trong JWT (payload không mã hoá!)
- Nhớ set expiry hợp lý cho token.
- Luôn dùng HTTPS.
- Refresh Token nên lưu httpOnly + Secure cookie → tránh bị XSS.
Hy vọng bài viết giúp bạn hiểu rõ về JWT!