JWT là gì? Tìm hiểu cấu trúc 3 phần (Header, Payload, Signature). Tại sao JSON Web Token là giải pháp bảo mật API thay thế Session truyền thống? Xem ngay!
Khi “Session” trở nên lỗi thời
Ngày xưa, khi chúng ta làm web, việc đăng nhập rất đơn giản: Người dùng nhập mật khẩu -> Server lưu thông tin vào bộ nhớ (Session) -> Server gửi lại một cái bánh quy (Cookie) để đánh dấu.
Nhiều người thắc mắc JWT là gì và tại sao nó lại trở thành xu hướng thay thế Session trong các ứng dụng hiện đại.
Khởi đầu website của bạn thật mạnh mẽ, mượt mà với hệ thống hosting cấu hình cao cấp tại AZDIGI.
Nhưng khi thời đại của Mobile App và các Website một trang (SPA – Single Page App) như React hay Vue lên ngôi, cách làm cũ này bộc lộ quá nhiều yếu điểm: Server bị quá tải khi phải nhớ hàng triệu người dùng, và Cookie thì rất khó dùng trên ứng dụng di động.
Đó là lúc JWT ra đời và trở thành tiêu chuẩn vàng cho việc xác thực (Authentication).
Vậy JWT là gì? Tại sao nó được ví như chiếc “Hộ chiếu điện tử” giúp bạn đi lại tự do trong thế giới số mà không cần Server phải nhớ mặt? Hãy cùng tìm hiểu.
xem thêm: C# là gì? Ngôn ngữ lập trình “quyền lực” của Microsoft và chìa khóa vào thế giới Game Unity
JWT là gì?
JWT (viết tắt của JSON Web Token) là một tiêu chuẩn mở (RFC 7519), định nghĩa một cách nhỏ gọn và an toàn để truyền tải thông tin giữa các bên (Client và Server) dưới dạng đối tượng JSON.
Điểm đặc biệt nhất của JWT là thông tin được ký số (Digitally Signed). Điều này có nghĩa là thông tin trong JWT có thể được xác minh và tin cậy, đảm bảo không ai có thể chỉnh sửa nó trên đường truyền.
So sánh dễ hiểu (Analogy):
• Session (Truyền thống): Giống như bạn đi gửi áo khoác ở rạp hát. Bạn đưa áo, họ đưa bạn một cái thẻ nhựa có số (Session ID). Cái thẻ đó vô nghĩa nếu không tra cứu trong sổ ghi chép của nhân viên giữ đồ.
• JWT (Hiện đại): Giống như tấm Hộ chiếu. Trên hộ chiếu có sẵn ảnh, tên tuổi, và quan trọng nhất là con dấu mộc đỏ của chính phủ (Signature). Bất kỳ hải quan nào nhìn vào hộ chiếu cũng biết bạn là ai và hộ chiếu có thật hay không mà không cần gọi điện về nước bạn để kiểm tra. Bạn tự mang danh tính của mình theo (Stateless).
xem thêm: https://yourdomain.com/c-sharp-la-gi/
Cấu trúc 3 phần của một chuỗi JWT
Nếu bạn nhìn thấy một chuỗi JWT, nó trông rất lằng nhằng với các ký tự ngẫu nhiên. Nhưng thực tế, nó được chia làm 3 phần, ngăn cách nhau bởi dấu chấm .:
aaaaaa.bbbbbb.cccccc
Cụ thể:
1. Header (Tiêu đề): Cho biết loại token là JWT và thuật toán mã hóa được sử dụng (ví dụ: HMAC SHA256 hoặc RSA).
2. Payload (Dữ liệu): Chứa các thông tin (Claims) mà bạn muốn truyền tải, ví dụ: User ID, Tên đăng nhập, Quyền hạn (Admin/User), Thời gian hết hạn.
3. Signature (Chữ ký): Đây là phần quan trọng nhất để chống giả mạo. Server sẽ lấy Header + Payload + Một bí mật (Secret Key) để tạo ra chữ ký này.
Nhìn vào cấu trúc này, bạn sẽ hiểu rõ hơn JWT là gì và vì sao nó có thể tự xác thực mà không cần lưu trạng thái trên server.
Cơ chế hoạt động: Luồng xác thực bằng JWT
Quá trình đăng nhập bằng JWT diễn ra như sau:
1. Client: Gửi Username/Password lên Server.
2. Server: Kiểm tra đúng mật khẩu -> Tạo ra một chuỗi JWT (chứa thông tin user) -> Trả về cho Client.
3. Client: Lưu chuỗi JWT này lại (thường lưu ở Local Storage hoặc Cookie).
4. Client: Mỗi khi muốn lấy dữ liệu (ví dụ: xem trang cá nhân), Client gửi kèm JWT lên trong phần Header của request (Authorization: Bearer <token>).
5. Server: Kiểm tra chữ ký của JWT. Nếu đúng -> Trả về dữ liệu. Server không cần truy vấn Database để kiểm tra session nữa.
5. So sánh JWT và Session truyền thống
Tại sao JWT lại thay thế Session?
| Tiêu chí | Session-based Auth | Token-based Auth (JWT) |
| Lưu trữ | Lưu trên bộ nhớ Server. | Lưu tại máy Client (Trình duyệt/App). |
| Khả năng mở rộng (Scalability) | Khó. Nếu Server A lưu session, Server B sẽ không biết user đó. | Dễ. Token tự chứa thông tin, Server nào giải mã cũng được. |
| Hiệu năng | Tốn RAM của Server để nhớ user. | Server nhẹ gánh, không tốn RAM lưu trạng thái (Stateless). |
| Đa nền tảng | Khó dùng trên Mobile App (Android/iOS). | Dùng tốt trên mọi nền tảng (Web, Mobile, Desktop). |
Khi nào nên và không nên dùng JWT?
Nên dùng khi:
• Xây dựng RESTful API cho Mobile App hoặc Single Page App (React, Angular, Vue).
• Hệ thống Microservices (nhiều server nhỏ cần giao tiếp và xác thực lẫn nhau).
Cần cân nhắc khi:
• JWT có nhược điểm là khó thu hồi (revoke). Nếu hacker trộm được JWT của bạn, hắn có thể dùng nó cho đến khi token hết hạn. Với Session, ta chỉ cần xóa session trên server là xong. (Giải pháp: Dùng Access Token ngắn hạn kết hợp Refresh Token).
Kết luận
“Đến đây, chắc bạn đã hiểu JWT là gì và lý do nó trở thành lựa chọn hàng đầu cho các hệ thống xác thực hiện đại.
JWT là một bước tiến lớn trong công nghệ xác thực, giúp giải phóng Server khỏi gánh nặng lưu trữ và mở đường cho các ứng dụng đa nền tảng hiện đại.
Nếu bạn đang học làm Backend (NodeJS, Java, C#…) hay Frontend, việc hiểu rõ và biết cách triển khai JWT là kỹ năng bắt buộc phải có trong CV của một lập trình viên.
FAQ – Câu hỏi thường gặp
Thông tin trong JWT có bị lộ không?
Có. Payload của JWT chỉ được mã hóa Base64 (ai cũng dịch ngược được), chứ không được mã hóa bí mật (Encrypt). Do đó, không bao giờ được để thông tin nhạy cảm như Mật khẩu hay số thẻ tín dụng vào trong JWT.
JWT lưu ở đâu trên trình duyệt là an toàn nhất?
Có 2 chỗ phổ biến: LocalStorage (dễ làm nhưng dễ bị tấn công XSS) và HttpOnly Cookie (an toàn hơn, chống được XSS nhưng cần cấu hình kỹ để tránh CSRF).
Làm sao để đăng xuất (Logout) khi dùng JWT?
Vì Server không lưu trạng thái, nên về lý thuyết không thể “xóa” JWT từ phía Server. Cách logout đơn giản nhất là Client tự xóa token đang lưu trong bộ nhớ của mình đi.
