Giải Mã JWT

JWT Decoder thực sự làm gì

Một JSON Web Token (JWT) trông giống một chuỗi ký tự ngẫu nhiên dài, mờ đục, nhưng nó không được mã hóa bảo mật và không phải mã bí mật. Đây là một container nhỏ gọn, an toàn với URL, mang dữ liệu có cấu trúc giữa hai bên. Dán một token vào bộ giải mã ở trên và nó sẽ tách chuỗi đó ra và hiển thị JSON thực bên trong — siêu dữ liệu, các claim, token dành cho ai, và khi nào hết hạn. Mọi thứ đều diễn ra ngay trong trình duyệt của bạn. Token không bao giờ được tải lên, ghi log, hoặc gửi đi đâu, điều này cực kỳ quan trọng khi thứ bạn đang kiểm tra là thông tin xác thực phiên đang hoạt động.

Ba phần, hai dấu chấm

Mỗi JWT hợp lệ gồm ba chuỗi được mã hóa Base64url nối bằng dấu chấm: header.payload.signature. Ký tự dấu chấm đó là cách parser biết một phần kết thúc và phần tiếp theo bắt đầu, và đó là lý do tại sao token có số lượng dấu chấm sai sẽ bị từ chối trước khi bất cứ thứ gì khác được đọc.

Header là một JSON object nhỏ mô tả chính token. Nó hầu như luôn chứa typ (kiểu, thường là JWT) và alg — thuật toán ký, chẳng hạn HS256 (HMAC với SHA-256) hoặc RS256 (RSA với SHA-256). Header cho bộ xác minh biết chính xác cách signature được tạo ra.

Payload là phần hầu hết mọi người quan tâm. Đây là một JSON object khác chứa các claim — các câu lệnh về người dùng và token. Đặc tả phân loại claim thành đã đăng ký (tên tiêu chuẩn, được bảo lưu), công khai, và riêng tư (tên tùy chỉnh bạn tự đặt cho ứng dụng của mình). Giải mã payload sẽ tiết lộ ai đang đăng nhập, họ có vai trò gì, và khi nào phiên của họ hết hạn.

Signature là con dấu mật mã. Nó được tính toán trên header và payload đã mã hóa bằng thuật toán từ header cộng với khóa bí mật hoặc khóa riêng tư. Vì nó bao trùm cả hai phần kia, bất kỳ thay đổi nào đối với header hoặc payload — dù chỉ một ký tự — đều làm signature không hợp lệ.

Các claim bạn sẽ thấy thường xuyên nhất

Các claim đã đăng ký là tên ba chữ cái ngắn được định nghĩa bởi RFC 7519 để các hệ thống khác nhau có thể tương tác. Một vài cái xuất hiện ở hầu hết mọi nơi:

• iss — issuer: ai đã tạo ra token (server xác thực hoặc nhà cung cấp danh tính của bạn).
• sub — subject: chủ thể mà token nói về, thường là ID người dùng ổn định.
• aud — audience: người nhận mà token được dùng cho. API nên từ chối các token có audience không phải chính nó.
• exp — expiration time: timestamp Unix sau đó token không được chấp nhận.
• iat — issued at: timestamp Unix khi token được tạo ra.

Bạn cũng có thể gặp nbf (not before) và jti (ID token duy nhất). Timestamp là giây kể từ năm 1970 theo UTC, đó là lý do tại sao bộ giải mã hiển thị chúng dưới dạng ngày có thể đọc được sẽ giúp bạn tránh phép tính tâm lý để kiểm tra xem token đã hết hạn chưa.

Giải mã không phải là xác minh — đây là phần khiến mọi người mắc bẫy

Sự phân biệt này là điều quan trọng nhất cần hiểu về JWT. Giải mã có nghĩa là đọc nội dung: không cần khóa và bất kỳ ai giữ token đều có thể làm, vì Base64url là encoding, không phải mã hóa bảo mật. Xác minh có nghĩa là chứng minh token là xác thực và chưa bị giả mạo — tính toán lại signature bằng khóa bí mật hoặc khóa công khai chính xác và xác nhận nó khớp.

Công cụ này giải mã. Nó hiển thị cho bạn những gì token nói, không phải liệu token có đáng tin không. Một token có thể bị giả mạo, hết hạn, hoặc bị phát lại và vẫn giải mã thành JSON trông hoàn toàn sạch sẽ. Đừng bao giờ đưa ra quyết định ủy quyền chỉ dựa trên các claim đã giải mã. Trong môi trường production, bạn xác minh signature phía server, kiểm tra exp, và xác nhận iss và aud khớp với những gì bạn mong đợi — sử dụng thư viện đã được kiểm chứng, không bao giờ so sánh chuỗi tự viết.

Payload không phải là kho bí mật

Vì payload chỉ được mã hóa Base64url, bất kỳ ai chặn được token đều có thể đọc nó. Hãy xem mọi thứ trong đó là công khai. Đừng đặt mật khẩu, số thẻ tín dụng đầy đủ, khóa bí mật, hoặc bất kỳ dữ liệu cá nhân nhạy cảm nào vào JWT claim — nếu bạn có thể giải mã nó ở đây chỉ một cú nhấp, bất kỳ ai khác có bản sao cũng có thể làm vậy. Signature bảo vệ chống lại sửa đổi, không bao giờ chống lại việc đọc. Nếu bạn thực sự cần ẩn nội dung payload, đó là công việc cho JWE (token mã hóa), một đặc tả hoàn toàn khác.

Quyền riêng tư và các công cụ liên quan

Kiểm tra token là một hành động nhạy cảm, vì vậy bộ giải mã này chạy hoàn toàn phía client — quá trình phân tích là JavaScript thuần túy trong tab của bạn và không có gì rời khỏi máy của bạn. Dán session token vào công cụ có server backend đồng nghĩa với việc trao thông tin xác thực đang hoạt động cho bên thứ ba, đó chính xác là điều bạn nên tránh. Để hiểu về encoding bên dưới, xem công cụ Base64 của chúng tôi, và khám phá phần còn lại của công cụ dành cho lập trình viên để có thêm các tiện ích chạy trên thiết bị.

Câu hỏi thường gặp