Why doesn't this tool verify the JWT signature?

Signature verification requires the signing secret or public key, which is kept private on your server. This tool decodes and displays the header and payload for inspection, but cryptographic verification must happen on your backend. Never trust an unsigned or unverified JWT in production.

What information can I see in a JWT payload?

The payload contains claims (data assertions) such as: exp (expiration time), iss (issuer), sub (subject/user), aud (audience), and custom claims. Always check the exp claim to ensure the token hasn't expired. Additional claims depend on how the token was issued.

Is this tool secure for sensitive data?

Yes, all processing runs entirely in your browser. No data is sent to any server, making it safe for sensitive information.

Công cụ giải mã JWT miễn phí

Giải mã và kiểm tra JSON Web Token · header, payload, claim và thời hạn.

Dán token JWT

Header

Payload

Signature

Về JWT

JSON Web Token (JWT) là một cách gọn nhẹ để biểu diễn các claim giữa hai bên. Chúng gồm ba phần: header (thuật toán và loại token), payload (các claim như issuer, thời hạn, subject) và signature. Công cụ này giải mã header và payload nhưng không xác minh chữ ký · để xác minh, bạn cần khóa bí mật hoặc khóa công khai dùng ký token. Toàn bộ việc giải mã diễn ra trong trình duyệt của bạn; token của bạn không được gửi đi đâu cả.

Lịch sử ngắn của JSON Web Token

JSON Web Token (JWT) đã được chuẩn hóa thành RFC 7519 vào tháng 5 năm 2015 bởi Michael B. Jones (Microsoft), John Bradley (Ping Identity) và Nat Sakimura (NRI) dưới Nhóm Công tác JOSE của IETF. Đó là đỉnh cao của nửa thập kỷ làm việc: bản dự thảo internet JWT đầu tiên xuất hiện vào tháng 12 năm 2010, phát triển từ định dạng khẳng định dựa trên XML nặng nề của SAML 2.0 (2005) và nhu cầu cảm nhận về một cái gì đó nhẹ hơn mà các trình duyệt có thể phân tích nguyên bản. Bước đột phá là chọn JSON thay vì XML và base64url thay vì PEM: một JWT có thể vừa trong chuỗi truy vấn URL hoặc tiêu đề Authorization: Bearer. Toàn bộ gia đình JOSE được gửi như một bộ phối hợp: RFC 7515 (JWS) để ký, RFC 7516 (JWE) để mã hóa, RFC 7517 (JWK) cho định dạng khóa, RFC 7518 (JWA) cho định danh thuật toán và RFC 7519 (JWT) cho lớp khai báo, tất cả vào cùng một ngày trong tháng 5 năm 2015. Việc áp dụng là ngay lập tức. OAuth 2.0 (RFC 6749, 2012) đã chuẩn hóa các token truy cập nhưng để định dạng của chúng không rõ ràng; ngành đã chọn JWT. OpenID Connect (tháng 12 năm 2014, OpenID Foundation) đã làm cho JWT bắt buộc đối với các token ID. Đến năm 2017, mọi nhà cung cấp danh tính chính (Auth0, Okta, Azure AD, AWS Cognito, Google Identity, Firebase Auth) đều phát hành JWT làm định dạng phiên bản gốc của họ. JWT.io, trang web giải mã mà Auth0 ra mắt vào năm 2014, đã trở thành công cụ gỡ lỗi JWT trên thực tế và giúp cố định thị phần nhận thức của các nhà phát triển đối với định dạng. Hai sự cố bảo mật đã định hình mô hình mối đe dọa hiện đại: tiết lộ năm 2015 của Tim McLean về bypass alg: none và cuộc tấn công nhầm lẫn thuật toán HS/RS, và CVE-2022-21449 (tháng 4 năm 2022), lỗi «Psychic Signatures» của Neil Madden trong trình xác minh ECDSA của Java 15-18. Cả hai đều dẫn đến việc tăng cường mặc định của thư viện: hầu hết các thư viện hiện đại bây giờ từ chối alg: none ngay lập tức và ghim thuật toán dự kiến thay vì đọc nó từ tiêu đề token.

Giải phẫu của một JWT

Ba phân đoạn được mã hóa base64url. JWT là chuỗi header.payload.signature: ba phân đoạn được phân tách bởi dấu chấm, mỗi phân đoạn được mã hóa base64url. RFC 7519 gọi đây là JWT Compact Serialization. Toàn bộ vừa với URL hoặc tiêu đề HTTP; sự gọn nhẹ đó là mục tiêu thiết kế phân biệt JWT với các tiền nhiệm dựa trên XML như SAML.
Tiêu đề. Một đối tượng JSON nhỏ thường chứa hai trường: alg (thuật toán ký, ví dụ HS256, RS256, ES256) và typ (hầu như luôn luôn «JWT»). Các trường tùy chọn bao gồm kid (định danh khóa được sử dụng để xoay khóa) và cty (loại nội dung cho các token lồng nhau). Tiêu đề cho trình xác minh biết cách xác thực chữ ký; đừng bao giờ tin tưởng nó một mình, luôn ghim thuật toán dự kiến phía máy chủ.
Payload. Một đối tượng JSON của các khai báo, các khẳng định khóa-giá trị về một chủ thể. RFC 7519 §4.1 đặt trước bảy khai báo tiêu chuẩn: iss (người phát hành), sub (chủ thể), aud (đối tượng), exp (hết hạn), nbf (không trước), iat (phát hành lúc) và jti (ID JWT duy nhất). Người phát hành thêm các khai báo tùy chỉnh tự do. Payload được ký nhưng không mã hóa: bất kỳ ai có token đều có thể đọc nó.
Chữ ký. Bằng chứng mật mã rằng tiêu đề và payload chưa bị giả mạo. Đầu vào ký là chuỗi nghĩa đen base64url(header) + "." + base64url(payload); chữ ký sau đó được mã hóa base64url làm phân đoạn thứ ba. Xác minh yêu cầu bí mật đối xứng (HS*) hoặc khóa công khai bất đối xứng (RS*, ES*, PS*, EdDSA) và phải luôn xảy ra trên một máy chủ đáng tin cậy.
base64url, không phải base64. Các phân đoạn JWT sử dụng biến thể base64 an toàn cho URL được định nghĩa trong RFC 4648 §5: ký tự 62 là - thay vì +, ký tự 63 là _ thay vì /, và phần đệm = ở cuối được loại bỏ. atob() tích hợp của JavaScript chỉ xử lý base64 tiêu chuẩn, vì vậy các bộ giải mã JWT dịch bảng chữ cái và đệm lại trước khi giải mã.
NumericDate: giây, không phải mili giây. RFC 7519 định nghĩa exp, nbf, và iat là «số giây từ 1970-01-01T00:00:00Z UTC». Date.now() của JavaScript trả về mili giây, vì vậy một lỗi phổ biến là một exp lớn hơn ba bậc độ lớn, tạo ra một token «hết hạn» vào khoảng năm 53.000. Luôn sử dụng Math.floor(Date.now() / 1000) khi đúc token.

Nơi JWT được sử dụng trong thực tế

Token truy cập OAuth 2.0. RFC 6749 đã để định dạng token truy cập không rõ ràng, nhưng trong thực tế ngành đã chuẩn hóa trên JWT. Auth0, Okta, Azure AD, AWS Cognito và Google Identity đều phát hành token truy cập JWT theo mặc định. Token Bearer trong tiêu đề Authorization của bạn hầu như luôn là JWT.
Token ID OpenID Connect. OIDC (tháng 12 năm 2014) bắt buộc JWT cho id_token của nó. id_token mang các khai báo danh tính về người dùng được xác thực (sub, email, name, picture) và được tiêu thụ bởi bên dựa vào thay vì chuyển tiếp. Đây là cơ chế chính đằng sau «Đăng nhập với Google», «Đăng nhập với Apple» và các luồng tương đương.
Xác thực API. Các API REST không trạng thái áp dụng JWT vì nó loại bỏ nhu cầu về một kho lưu trữ phiên phía máy chủ: API tin tưởng những gì chữ ký xác minh. Các khóa API kiểu Stripe vẫn phổ biến cho lưu lượng máy chủ-tới-máy chủ, nhưng đối với các API có phạm vi người dùng, mẫu Authorization: Bearer <jwt> bây giờ là mặc định.
Xác thực microservice-tới-microservice. Một JWT có phạm vi người dùng được đúc tại cạnh API được chuyển tiếp qua các cuộc gọi dịch vụ-tới-dịch vụ nội bộ, cho phép mỗi dịch vụ tin tưởng xác thực ban đầu mà không cần xác thực lại. Mẫu này đôi khi được gọi là «dịch token»: cổng cạnh trao đổi một phiên không rõ ràng cho một JWT có thời gian ngắn được giới hạn cho cuộc gọi downstream.
Phiên ứng dụng một trang. SPA (React, Vue, Angular) trong lịch sử đã lưu trữ token truy cập trong localStorage để thuận tiện. Hướng dẫn hiện đại (OWASP, Auth0) là giữ token truy cập trong bộ nhớ và token làm mới trong cookie HttpOnly + Secure + SameSite=Strict, vì localStorage có thể đọc được bởi bất kỳ XSS nào đáp xuống trên trang.
Phiên ứng dụng di động. Các ứng dụng iOS và Android lưu trữ token truy cập trong Keychain hoặc Keystore của nền tảng. Token được gửi dưới dạng Authorization: Bearer trong mỗi cuộc gọi backend. Token làm mới được xoay vòng trong mỗi lần sử dụng, và exp ngắn của token truy cập (thường 5-15 phút) là tuyến phòng thủ chính chống lại việc phát lại thiết bị bị đánh cắp.

Các tiêu chuẩn và cột mốc bảo mật

RFC 7519 (JWT, tháng 5 năm 2015). Đặc tả cơ sở. Định nghĩa JWT Compact Serialization, bảy khai báo tiêu chuẩn đã đăng ký (iss, sub, aud, exp, nbf, iat, jti) và định dạng NumericDate. Tác giả: Michael B. Jones, John Bradley, Nat Sakimura.
RFC 7515 (JWS, tháng 5 năm 2015). JSON Web Signature. Định dạng bọc đã ký mà gần như mọi người gọi không chính thức là «JWT»: ba phân đoạn base64url được nối bởi dấu chấm. JWS hỗ trợ cả hai dạng nhỏ gọn và JSON Serialization; JWT chỉ sử dụng dạng nhỏ gọn.
RFC 7516 (JWE, tháng 5 năm 2015). JSON Web Encryption. Biến thể được mã hóa với năm phân đoạn (tiêu đề, khóa được mã hóa, IV, văn bản mã hóa, thẻ xác thực). Sử dụng JWE, không phải JWS, khi payload phải bí mật, không chỉ rõ ràng giả mạo.
RFC 7517 (JWK, tháng 5 năm 2015). JSON Web Key. Biểu diễn JSON của các khóa mật mã. Điểm cuối JWKS (/.well-known/jwks.json) xuất bản một JSON Web Key Set, cơ chế hiện đại cho việc xoay khóa không có thời gian chết: các trình xác minh tìm kiếm khóa theo kid.
RFC 7518 (JWA, tháng 5 năm 2015). JSON Web Algorithms. Đăng ký các định danh alg: HS256/384/512 (HMAC), RS256/384/512 (RSASSA-PKCS1-v1_5), ES256/384/512 (ECDSA), PS256/384/512 (RSASSA-PSS), EdDSA (Ed25519/Ed448) và none (có chủ ý hiếm khi được sử dụng).
Bypass alg: none (Tim McLean, 2015). RFC 7518 liệt kê none là một giá trị thuật toán hợp lệ cho các bối cảnh không an toàn. Các trình xác minh ngây thơ sẽ chấp nhận một token với tiêu đề được viết lại thành {"alg":"none"} và chữ ký trống, cho phép kẻ tấn công giả mạo bất kỳ payload nào. Các thư viện hiện đại từ chối none theo mặc định; đặc tả tự nó nêu rõ rằng các trình xác minh «KHÔNG ĐƯỢC chấp nhận JWS Không an toàn theo mặc định».
Cuộc tấn công nhầm lẫn thuật toán HS/RS (Tim McLean, 2015). Nếu một trình xác minh chọn thuật toán từ tiêu đề token thay vì ghim nó, kẻ tấn công có thể viết lại tiêu đề thành HS256 và ký token bằng cách sử dụng khóa công khai RSA của máy chủ làm bí mật HMAC. Thư viện thấy HS256, coi khóa công khai RSA được cấu hình là một bí mật đối xứng và chữ ký được kiểm tra. Giảm thiểu: ghim thuật toán dự kiến ngoài băng tần; không bao giờ suy ra nó từ token.
CVE-2022-21449 «Psychic Signatures» (Neil Madden, tháng 4 năm 2022). Trình xác minh ECDSA của Java 15-18 không kiểm tra rằng các giá trị r và s của chữ ký khác không, có nghĩa là một chữ ký nghĩa đen toàn số không được chấp nhận là hợp lệ. JWT được ký bằng ES256/384/512 trên các JVM bị ảnh hưởng có thể bị giả mạo với một chữ ký trống. Đã được vá trong Bản cập nhật Vá Quan trọng của Oracle tháng 4 năm 2022.

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

Tại sao công cụ này không xác minh chữ ký?

Xác minh cần một bí mật (HMAC) hoặc khóa công khai (RSA / ECDSA / EdDSA). Việc dán bí mật HMAC sản xuất vào bất kỳ trang web nào là một rò rỉ thông tin xác thực, ngay cả trên một công cụ thề không truyền bất cứ điều gì. Xác minh thuộc về một máy chủ bạn kiểm soát. Công việc của bộ giải mã là làm cho nội dung có thể đọc được để bạn có thể thấy những gì trình xác minh của bạn nên kiểm tra.

Có an toàn để dán các token sản xuất thực ở đây không?

Giải mã xảy ra hoàn toàn trong trình duyệt của bạn. Token không được gửi qua mạng, ghi vào bất kỳ nhật ký nào, hoặc lưu trữ ở bất cứ đâu. Nói vậy, một JWT thường là một thông tin xác thực: bất kỳ ai nắm giữ một token truy cập chưa hết hạn đều có thể hành động như người dùng. Quy ước cộng đồng là «đối xử với JWT sản xuất như một cookie phiên»: ưu tiên token thử nghiệm khi bạn có thể, và xoay vòng bất kỳ token thực nào bạn đã chia sẻ ở bất cứ đâu ngoài phiên trình duyệt đã đúc nó.

Tôi nên lưu trữ một JWT ở đâu trong trình duyệt?

Hai mẫu phổ biến mỗi mẫu có một sự đánh đổi. localStorage thuận tiện nhưng có thể đọc được bởi bất kỳ cuộc tấn công XSS thành công nào trên trang. Cookie với HttpOnly không nhìn thấy đối với JavaScript nên XSS không thể đọc chúng, nhưng chúng cần SameSite=Strict hoặc SameSite=Lax để tránh CSRF. Thực hành tốt nhất hiện tại: token truy cập có thời gian ngắn trong một biến JavaScript (chỉ bộ nhớ) cộng với một token làm mới có thời gian dài trong cookie HttpOnly + Secure + SameSite=Strict có phạm vi cho điểm cuối làm mới, được xoay vòng trong mỗi lần sử dụng.

Trường kid trong tiêu đề làm gì?

Nó xác định khóa nào đã ký token. Các nhà cung cấp danh tính hiện đại xuất bản khóa công khai của họ tại điểm cuối /.well-known/jwks.json dưới dạng JWK Set (RFC 7517); trình xác minh tìm kiếm khóa có kid khớp với tiêu đề của token. Đây là điều khiến cho việc xoay khóa không có thời gian chết là có thể: cả khóa cũ và mới có thể nằm trong JWKS trong giai đoạn ân hạn.

Tôi có thể thu hồi một JWT sau khi nó đã được phát hành không?

Không thể nguyên bản. Một JWT được ký có hiệu lực cho đến khai báo exp của nó; sự không trạng thái đó là thuộc tính tiêu đề của định dạng. Giải pháp thay thế: giữ token truy cập ngắn (5-15 phút) ghép với một token làm mới có thể thu hồi; duy trì danh sách từ chối phía máy chủ các giá trị jti đã thu hồi; xoay khóa ký (làm cho mọi token chưa được giải quyết được ký bằng nó không hợp lệ). Mỗi tùy chọn giới thiệu lại một số trạng thái; đó là sự đánh đổi.

Giải mã một token có giống như giải mật mã nó không?

Không. Giải mã đảo ngược base64url trở lại JSON: bất kỳ ai cũng có thể làm điều đó, và đó là điểm. Giải mật mã yêu cầu một khóa và chỉ áp dụng cho JSON Web Encryption (JWE, RFC 7516), là biến thể được mã hóa của họ JOSE. Hầu hết các token bạn thấy trong tự nhiên là JWS (đã ký nhưng chưa được mã hóa), vì vậy giải mã là đủ để đọc chúng.