Mã hóa/Giải mã JWT

Mã hóa/Giải mã JWT - Tạo và Decode JSON Web Tokens Online

Công cụ mã hóa và giải mã JWT (JSON Web Token) online mạnh mẽ cho phép bạn tạo JWT tokens mới hoặc giải mã, kiểm tra và hiểu tokens hiện có ngay lập tức. Mã hóa header và payload với HMAC signing (HS256, HS384, HS512), hoặc giải mã header (JOSE header), payload (claims) và signature của bất kỳ JWT token nào. Xem các claims chuẩn như issuer, subject, audience, expiration time và nhiều hơn nữa. Hoàn hảo cho lập trình viên, chuyên gia bảo mật và bất kỳ ai làm việc với xác thực JWT, OAuth 2.0, OpenID Connect và bảo mật API.

JWT là gì và có cấu trúc thế nào?

JSON Web Token (JWT, đọc là "jot") là một chuẩn mở (RFC 7519) để biểu diễn các tuyên bố dưới dạng chuỗi gọn và an toàn cho URL. JWT có ba phần mã hóa Base64URL nối bằng dấu chấm: header.payload.signature. Header khai báo thuật toán ký và loại token ({"alg":"HS256","typ":"JWT"}). Payload chứa các claim như sub (chủ thể), iss (bên phát hành), exp (hết hạn) và dữ liệu tùy biến. Chữ ký được tính bằng cách băm header+payload đã mã hóa với một bí mật (HMAC) hoặc ký bằng khóa riêng (RSA/ECDSA). Token là base64url, không phải base64, nên an toàn để đặt trong URL và header HTTP. JWT không trạng thái: máy chủ xác thực chữ ký mỗi yêu cầu mà không cần truy vấn cơ sở dữ liệu. RFC 7519 là đặc tả JWT; RFC 7515 bao quát JWS (đã ký) và RFC 7516 bao quát JWE (đã mã hóa).

Lỗ hổng alg=none là gì và làm sao ngăn chặn?

alg=none là lỗ hổng JWT nổi tiếng nhất, có trong danh sách OWASP API Security Top 10. Token ký với alg=none không có chữ ký gì cả — nhưng nhiều thư viện cũ chấp nhận nó là "hợp lệ" vì trường thuật toán trong header được tôn trọng mà không kiểm tra với danh sách trắng. Kẻ tấn công có thể lấy token thật, đổi header thành {"alg":"none"}, bỏ chữ ký, sửa payload (ví dụ role=admin), và bộ xác thực hỏng sẽ cho qua. Cách khắc phục là duy trì danh sách trắng nghiêm ngặt các thuật toán chấp nhận được phía máy chủ (ví dụ chỉ HS256 hoặc RS256) và từ chối mọi thứ khác — không bao giờ tin claim alg từ chính token. Lỗi đi kèm là nhầm lẫn HS256/RS256: kẻ tấn công gửi token HS256 ký bằng khóa công khai RSA của máy chủ làm bí mật HMAC. Luôn cố định thuật toán mong đợi theo từng khóa.

HS256, RS256 và ES256 khác nhau thế nào?

HS256 (HMAC-SHA256) dùng một bí mật chia sẻ duy nhất cho cả ký và xác thực — nhanh và đơn giản nhưng bên nào xác thực được cũng giả mạo được. Chỉ dùng khi bên phát hành và bên xác thực là cùng một dịch vụ. RS256 (RSA-SHA256) dùng mã hóa bất đối xứng: khóa riêng ký, khóa công khai xác thực. Đây là chuẩn cho OAuth/OIDC vì các nhà cung cấp định danh (Auth0, Okta, Google) công bố endpoint JWKS (JSON Web Key Set) chứa khóa công khai để client lấy về xác thực token. ES256 (ECDSA P-256) cũng bất đối xứng nhưng dùng đường cong elliptic, tạo chữ ký ngắn hơn nhiều (~64 byte so với ~256 byte của RS256) — tốt cho kịch bản hạn chế băng thông. EdDSA (RFC 8037) dùng Ed25519 là khuyến nghị hiện đại: nhanh hơn, nhỏ hơn và kháng nhiều tấn công thời gian. Tránh RS256 với khóa dưới 2048 bit.

Các claim đăng ký chuẩn (iss, sub, aud, exp, nbf, iat, jti) là gì?

RFC 7519 định nghĩa bảy claim đăng ký, đều tùy chọn nhưng được khuyến nghị. iss (issuer) cho biết ai tạo token. sub (subject) là ID người dùng. aud (audience) liệt kê người nhận dự định — dịch vụ của bạn phải từ chối token mà định danh của nó không nằm trong aud. exp (expiration) là dấu thời gian Unix mà sau đó token phải bị từ chối — giữ ngắn (15 phút cho token truy cập). nbf (not before) là thời điểm sớm nhất token hợp lệ, hữu ích cho kích hoạt theo lịch. iat (issued at) ghi khi token được tạo. jti (JWT ID) là định danh duy nhất mỗi token, cho phép danh sách thu hồi hoặc phát hiện phát lại. Mọi claim thời gian là NumericDate (giây Unix từ 1970 UTC). Luôn xác thực exp, nbf, iss và aud — bỏ qua bất kỳ cái nào là bypass phổ biến.

Nên lưu JWT ở trình duyệt nơi nào — cookie hay localStorage?

Không có lựa chọn nào hoàn hảo. localStorage dễ bị XSS: bất kỳ script nào trên cùng origin đều đọc được và đánh cắp token. Cookie dễ bị CSRF nếu không cấu hình đúng, nhưng biện pháp giảm thiểu đã rõ ràng. Mẫu OWASP khuyến nghị là cookie httpOnly + Secure + SameSite=Strict (hoặc Lax) cho JWT, kết hợp với token CSRF trong header cho yêu cầu thay đổi trạng thái. httpOnly chặn JavaScript truy cập (vô hiệu hóa đánh cắp qua XSS), Secure ép HTTPS, và SameSite giới hạn gửi cookie giữa các site. Cho SPA + API trên origin khác, có thể cần SameSite=None; Secure cộng CORS rõ ràng. Hoàn toàn tránh lưu refresh token thời hạn dài trong localStorage. Nếu phải dùng localStorage, coi mọi XSS như chiếm quyền tài khoản hoàn toàn và đầu tư mạnh vào header Content Security Policy.

Refresh token hoạt động thế nào và vì sao cần?

Token truy cập JWT nên có thời hạn ngắn (5-15 phút) để token bị lộ có giá trị hạn chế. Nhưng buộc người dùng đăng nhập lại mỗi 15 phút là UX kém, nên OAuth 2.0 đưa ra refresh token — chuỗi mờ thời hạn dài đổi ở endpoint /token lấy token truy cập mới. Refresh token thường lưu trong cookie httpOnly và chỉ gửi đến máy chủ xác thực. Thực hành tốt: xoay refresh token mỗi lần dùng (RFC 6749bis), thu hồi cả họ token nếu bị phát lại (phát hiện tái sử dụng), gắn refresh token với client (PKCE), và lưu phía máy chủ đã băm để rò rỉ DB không lộ chúng. Client công khai (SPA, ứng dụng di động) nên dùng luồng PKCE. Refresh token là mục tiêu giá trị cao — bảo vệ như mật khẩu.

JWT, JWS, JWE và JWK khác nhau thế nào?

Đây là bốn đặc tả liên quan nhưng khác biệt trong họ JOSE (JSON Object Signing and Encryption). JWS (RFC 7515) là cấu trúc JSON đã ký — cái người ta thường gọi là "JWT." JWE (RFC 7516) là cấu trúc mã hóa với năm phần (header.encryptedKey.iv.ciphertext.tag) trong đó payload bị ẩn, không chỉ ký. JWT (RFC 7519) là định dạng payload (claim) có thể bọc trong JWS hoặc JWE. JWK (RFC 7517) là biểu diễn JSON của khóa mật mã, và JWKS là tập khóa — thường công bố tại /.well-known/jwks.json bởi nhà cung cấp định danh. Dùng JWS khi payload không nhạy cảm (chỉ ký để toàn vẹn), dùng JWE khi payload phải bảo mật (ví dụ chứa PII). Hầu hết luồng OAuth dùng JWS, không phải JWE.

Thông tin nào nên tránh đưa vào payload JWT?

Payload JWT được mã hóa Base64URL, KHÔNG phải mã hóa bảo mật — ai có token đều đọc được mọi claim. Đừng bao giờ đưa mật khẩu, số an sinh xã hội, dữ liệu thẻ tín dụng, bí mật API hoặc PII chịu GDPR/HIPAA/PCI vào payload JWT trừ khi dùng mã hóa JWE. Cũng tránh dữ liệu lớn: mỗi yêu cầu mang toàn bộ token trong header Authorization, payload phình to lãng phí băng thông mỗi lệnh gọi API. Giữ claim ở định danh và phạm vi ủy quyền (ID người dùng, vai trò, hết hạn). Cho tra cứu nhạy cảm, lưu dữ liệu phía máy chủ khóa bằng claim sub. Cũng tránh đưa dữ liệu người dùng biến động (tên hiển thị, email) có thể đổi — JWT đã cache sẽ hiện giá trị cũ đến khi hết hạn. Token là bằng chứng năng lực, không phải hồ sơ người dùng.

Tính năng chính

• Giải mã JWT tokens ngay lập tức
• Xem header (JOSE header) với thuật toán và loại token
• Xem payload với tất cả claims và dữ liệu tùy chỉnh
• Xem signature (base64url encoded)
• Tự động phát hiện các JWT claims chuẩn (iss, sub, aud, exp, nbf, iat, jti)
• Định dạng timestamp dễ đọc cho các date claims
• Kiểm tra trạng thái hết hạn token
• Hỗ trợ tất cả các thuật toán JWT (HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512)
• Làm nổi bật cú pháp JSON và định dạng
• Phần thông tin claims với giải thích chi tiết
• Sao chép các phần đã giải mã vào clipboard
• Tải xuống output đã giải mã
• Tải lên file JWT để giải mã
• Hỗ trợ chế độ tối
• Xử lý 100% phía client - tokens không bao giờ rời khỏi trình duyệt của bạn
• Hoạt động offline sau khi tải lần đầu
• Không giới hạn kích thước token
• Thiết kế responsive thân thiện với mobile
• Thông báo lỗi rõ ràng cho tokens không hợp lệ
• Thông tin giáo dục về bảo mật JWT
• Không cần đăng ký hoặc đăng nhập