JWT Là Gì? Giải Thích Dễ Hiểu Cho Người Mới

Câu trả lời nhanh
JWT (JSON Web Token) là chuẩn mở truyền thông tin an toàn giữa các hệ thống dưới dạng JSON có ký số. JWT gồm 3 phần: Header, Payload, Signature. Khi đăng nhập, server tạo JWT gửi cho client, client đính kèm token vào request tiếp theo. Ưu điểm lớn nhất là stateless - server không cần lưu session, dễ mở rộng. Nên dùng cho API, SSO, microservices.

JWT Là Gì?

JWT (JSON Web Token) là một chuẩn mở dùng để truyền thông tin an toàn giữa các bên dưới dạng JSON. Thông tin này được số hóa và ký bằng mật khẩu hoặc khóa bí mật, giúp người nhận có thể xác minh tính xác thực của dữ liệu.

Nói đơn giản hơn, JWT giống như một tấm vé điện tử. Khi bạn đăng nhập vào một website, server tạo ra một chuỗi JWT gửi cho bạn. Lần sau khi bạn truy cập, chỉ cần xuất trình tấm vé này, server biết ngay bạn là ai mà không cần đăng nhập lại.

Cấu Trúc Của JWT Như Thế Nào?

Một JWT hoàn chỉnh gồm 3 phần, ngăn cách nhau bởi dấu chấm:

Header.Payload.Signature

Mỗi phần đều được mã hóa Base64Url. Cùng phân tích từng phần nhé.

1. Header (Phần đầu)

Header chứa hai thông tin chính: loại token (thường là JWT) và thuật toán ký được sử dụng (như HMAC SHA256 hay RSA). Phần này cho server biết cách xử lý token.

2. Payload (Phần tải)

Payload là nơi chứa dữ liệu thực sự, còn gọi là các claims. Đây là thông tin về người dùng hoặc thực thể, ví dụ như ID người dùng, vai trò, thời gian hết hạn. Mỗi claim là một cặp key-value trong JSON.

Một số claim phổ biến bao gồm iss (issuer, bên phát hành), exp (expiration, thời gian hết hạn), và sub (subject, chủ thể của token).

3. Signature (Phần chữ ký)

Signature là phần quan trọng nhất. Server dùng khóa bí mật để tạo chữ ký từ Header và Payload. Bất kỳ ai cũng có thể đọc nội dung JWT, nhưng không ai có thể thay đổi nó nếu không có khóa ký.

Điều này có nghĩa là khi server nhận lại token, nó kiểm tra chữ ký để chắc chắn nội dung không bị chỉnh sửa trên đường truyền.

Cách JWT Hoạt Động Trong Thực Tế?

Quy trình xác thực bằng JWT thường diễn ra như sau:

Đầu tiên, người dùng nhập tên đăng nhập và mật khẩu. Server kiểm tra thông tin, nếu hợp lệ sẽ tạo JWT và trả về cho client. Client lưu token này (trong localStorage, sessionStorage, hoặc cookie).

Ở các request tiếp theo, client đính kèm JWT vào header theo dạng Authorization: Bearer <token>. Server nhận token, kiểm tra chữ ký và thời gian hết hạn, rồi xử lý request.

Toàn bộ quá trình này không cần server lưu trữ session, đây là điểm khác biệt lớn so với xác thực truyền thống.

JWT Khác Gì So Với Session Truyền Thống?

Với session truyền thống, server phải lưu trạng thái đăng nhập của mỗi người dùng trong bộ nhớ hoặc database. Khi có 10.000 người dùng cùng lúc, server tốn nhiều tài nguyên để quản lý session.

JWT giải quyết vấn đề này bằng cách không lưu trạng thái (stateless). Mọi thông tin cần thiết đã nằm trong token. Server chỉ việc kiểm tra chữ ký, không cần tra cứu database cho mỗi request.

Điều này đặc biệt hữu ích khi bạn mở rộng hệ thống trên nhiều server. Không cần đồng bộ session giữa các server, mỗi server đều có thể xác thực token độc lập.

Khi Nào Nên Dùng JWT?

JWT phù hợp nhất cho các trường hợp sau:

Xác thực API: Khi bạn xây dựng REST API hoặc GraphQL API cho ứng dụng di động hay SPA (Single Page Application), JWT là lựa chọn phổ biến nhờ tính stateless.

Single Sign-On (SSO): JWT cho phép người dùng đăng nhập một lần và truy cập nhiều hệ thống khác nhau mà không cần xác thực lại.

Trao đổi thông tin an toàn: Ngay cả khi không dùng để xác thực, JWT cũng phù hợp khi cần truyền dữ liệu giữa các dịch vụ với tính toàn vẹn được đảm bảo.

Những Rủi Ro Cần Lưu Ý

JWT không phải là giải pháp hoàn hảo. Mình đã thấy nhiều team sử dụng JWT sai cách và tạo ra lỗ hổng bảo mật nghiêm trọng.

Lưu token không an toàn: Nếu bạn lưu JWT trong localStorage, mã JavaScript độc hại (như XSS) có thể đánh cắp token. Nhiều chuyên gia khuyến nghị lưu trong httpOnly cookie để giảm rủi ro.

Không thể thu hồi token: Vì JWT không lưu trạng thái, bạn không thể “đăng xuất” token trước khi nó hết hạn. Nếu token bị lộ, kẻ tấn công có thể sử dụng đến khi exp hết hiệu lực. Giải pháp là giữ thời gian hết hạn ngắn (15-30 phút) và dùng refresh token.

Nhầm lẫn giữa JWT mã hóa và JWT ký:

JWT mặc định chỉ (đảm bảo không bị thay đổi), không mã hóa (ẩn nội dung). Bất kỳ ai cũng có thể decode Payload và đọc nội dung. Đừng bỏ thông tin nhạy cảm như mật khẩu hay số thẻ tín dụng vào JWT.

Refresh Token Là Gì và Tại Sao Cần?

Vì access token (JWT) nên có thời gian ngắn, người dùng sẽ bị đăng xuất liên tục. Refresh token giải quyết vấn đề này.

Refresh token có thời hạn dài hơn (vài ngày đến vài tuần) và được lưu ở server. Khi access token hết hạn, client dùng refresh token để xin access token mới mà không cần đăng nhập lại.

Mô hình này cân bằng giữa bảo mật và trải nghiệm người dùng. Access token ngắn hạn giảm thiệt hại nếu bị lộ, trong khi refresh token duy trì phiên đăng nhập thuận tiện.

JWT Trong Hệ Sinh Thái WordPress

WordPress mặc định dùng cookie-based authentication, phù hợp cho website truyền thống. Nhưng khi bạn xây dựng headless WordPress hoặc REST API, JWT trở nên cần thiết.

Các plugin như JWT Authentication for WP REST API cho phép tích hợp JWT vào WordPress nhanh chóng. Lập trình viên có thể xây dựng ứng dụng riêng biệt giao tiếp với WordPress backend thông qua JWT, tận dụng ưu điểm stateless của nó.

Nên Dùng Thư Viện JWT Nào?

Đừng tự viết code tạo JWT. Sử dụng thư viện đã được kiểm chứng:

Node.js: jsonwebtoken là thư viện phổ biến nhất, được sử dụng trong hầu hết dự án Express.

Python: PyJWT nhẹ và dễ dùng, phù hợp cho Flask và Django.

PHP: firebase/php-jwt của Google, ổn định và được bảo trì tốt.

Go: golang-jwt là lựa chọn chuẩn cho hệ sinh thái Go.

Một nguyên tắc quan trọng: luôn dùng thư viện được community tin dùng, cập nhật thường xuyên. Các lỗ hổng JWT thường xuất phát từ việc implement sai chứ không phải bản thân chuẩn JWT.

Kết Luận

JWT là công cụ mạnh mẽ cho xác thực hiện đại, đặc biệt trong kiến trúc microservices và API-first. Tính stateless giúp hệ thống dễ mở rộng, không phụ thuộc session server.

Tuy nhiên, JWT không phải đạn bạc. Nếu xây dựng ứng dụng web truyền thống với server-side rendering, session cookie vẫn là lựa chọn đơn giản và an toàn hơn. Hiểu rõ ưu nhược điểm của JWT để dùng đúng chỗ, đúng cách mới là điều quan trọng.

ThienLv

Mình là Thien, người tạo ra blog này. Ban ngày làm marketing, ban đêm cày tiền online và chơi với AI. Blog này là nơi mình ghi lại những gì mình thử qua — tool nào xịn, chiến thuật nào chạy được, cái gì thất bại. Mình không giỏi nhất, nhưng mình thích chia sẻ thật. Chill với một ly cafe đá là lý tưởng nhất.

Xem tất cả bài viết →

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *