UltKit

Giải mã JWT

Dán JSON Web Token để đọc header và payload dưới dạng JSON đã định dạng, kèm thời điểm hết hạn và thời điểm phát hành hiển thị thành ngày giờ, cùng ghi chú cho biết token hiện còn hiệu lực hay không. Toàn bộ quá trình giải mã diễn ra trong trình duyệt của bạn, điều này rất quan trọng khi token là thông tin xác thực đang được sử dụng.

0 ký tự · 0 từ · 0 dòng

0 ký tự · 0 từ · 0 dòng

Chạy hoàn toàn trong tab trình duyệt này. Văn bản của bạn không bao giờ được tải lên hay lưu trữ.

Các claim đã đăng ký

Bảy tên claim được định nghĩa trong RFC 7519 §4.1. Tất cả đều tùy chọn; thời gian tính bằng giây kể từ 1970-01-01 UTC.

ClaimÝ nghĩa
issIssuer: bên tạo và ký token
subSubject: người dùng hoặc thực thể mà token nói đến
audAudience: đối tượng mà token hướng tới
expExpiration time: từ chối token sau thời điểm này
nbfNot before: từ chối token trước thời điểm này
iatIssued at: thời điểm token được tạo
jtiJWT ID: định danh duy nhất, dùng để chống phát lại

Các giá trị alg phổ biến

Giá trị algÝ nghĩa
HS256HMAC với SHA-256; một khóa bí mật dùng chung để ký và xác minh
RS256Chữ ký RSA PKCS#1 v1.5 với SHA-256; khóa riêng để ký, khóa công khai để xác minh
PS256RSA-PSS với SHA-256
ES256ECDSA trên đường cong P-256 với SHA-256; chữ ký ngắn
EdDSAChữ ký Ed25519 hoặc Ed448
noneToken không ký; máy chủ nên từ chối

Bên trong một JSON Web Token

JWT được định nghĩa trong RFC 7519 (tháng 5 năm 2015), tài liệu này gợi ý đọc là "jot" như từ tiếng Anh. Dạng có chữ ký phổ biến gồm ba chuỗi Base64url nối với nhau bằng dấu chấm: header.payload.signature. Header nêu thuật toán ký trong alg, chẳng hạn HS256 hoặc RS256, và thường có ID khóa trong kid. Payload chứa các claim, tức các trường JSON như sub (người dùng), iss (bên phát hành), aud (đối tượng nhận) cùng exp, nbf và iat, là các mốc thời gian tính bằng giây kể từ 00:00 ngày 1 tháng 1 năm 1970 UTC. Bộ giải mã đổi ba mốc này sang giờ địa phương và định dạng ISO 8601, đồng thời cho biết token đã hết hạn, chưa có hiệu lực hay đang trong thời hạn sử dụng.

Base64url là một cách mã hóa, không phải mã hóa bảo mật (encryption), nên bất kỳ ai có token đều đọc được payload giống hệt như trang này. Đừng bao giờ đặt mật khẩu, số thẻ hay thông tin bí mật khác vào claim. Token có năm phần ngăn cách bằng dấu chấm là JWE, tức token đã được mã hóa; không có khóa thì không đọc được nội dung, và bộ giải mã sẽ báo điều đó. Tiền tố "Bearer " khi sao chép từ header Authorization sẽ được tự động loại bỏ.

Vì sao công cụ này không xác minh chữ ký

Chữ ký chứng minh header và payload do người nắm khóa tạo ra và chưa bị thay đổi kể từ đó. Muốn kiểm tra phải có khóa: khóa bí mật dùng chung với các thuật toán HMAC như HS256, hoặc khóa công khai của bên phát hành với RS256, ES256 hay EdDSA. Dán khóa ký của môi trường production vào bất kỳ trang web nào đều là ý tồi, và một công cụ giải mã giả vờ xác nhận token mà không có khóa sẽ tạo cảm giác an toàn sai lầm, vì vậy công cụ này chỉ hiển thị chữ ký chứ không xác minh. Hãy coi những gì bạn thấy là điều token tự khẳng định, không phải sự thật.

Việc xác minh nên thực hiện trên máy chủ của bạn, dùng thư viện còn được bảo trì và cố định thuật toán mong đợi. Hai lỗi kinh điển cho thấy lý do: chấp nhận alg "none" khiến ai cũng có thể giả mạo token không có chữ ký, và nhầm lẫn thuật toán, khi máy chủ đang chờ RS256 bị đánh lừa để kiểm tra chữ ký HS256 bằng khóa công khai làm khóa bí mật HMAC. Bộ giải mã dùng để gỡ lỗi: xem nhà cung cấp phát hành những claim nào, phát hiện aud sai, hoặc biết phiên đăng nhập thất bại vì exp vừa qua một phút trước. Để đọc thô các đoạn Base64url, hãy dùng công cụ giải mã Base64.

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

Dán access token thật vào công cụ giải mã JWT có an toàn không?
Trên trang này, token không bao giờ rời khỏi trình duyệt của bạn. Tuy vậy, token hợp lệ có tác dụng như mật khẩu cho đến khi hết hạn, nên hãy ưu tiên dùng token đã hết hạn hoặc token thử nghiệm, và đừng để token đang dùng xuất hiện trong ảnh chụp màn hình hay tin nhắn.
Vì sao token vừa được cấp đã báo hết hạn?
Trước tiên hãy kiểm tra đồng hồ trên thiết bị. Một số bên phát hành chỉ cho access token sống vài phút, và token sao chép từ log có thể cũ hơn bạn nghĩ. Nếu exp được ghi bằng mili giây thay vì giây thì sẽ ngược lại, thời hạn rơi vào hàng nghìn năm sau.
Người khác có thể sửa payload của JWT không?
Họ có thể sửa và mã hóa lại, nhưng chữ ký sẽ không còn khớp. Máy chủ xác minh chữ ký bằng đúng khóa và thuật toán sẽ từ chối token đã bị thay đổi.
JWS và JWE khác nhau như thế nào?
JWS (RFC 7515) có chữ ký, gồm ba phần và ai cũng đọc được. JWE (RFC 7516) được mã hóa, gồm năm phần và chỉ người giữ khóa mới đọc được payload.
Đăng xuất có làm JWT mất hiệu lực không?
Tự nó thì không. JWT có chữ ký vẫn hợp lệ cho đến exp, trừ khi máy chủ giữ danh sách chặn hoặc kiểm tra bản ghi phiên, đó là lý do access token thường được đặt thời hạn ngắn.