Trình giải mã JWT
Giải mã bất kỳ JSON Web Token nào để xem phần header, payload và các claim ở dạng dễ đọc — và tùy chọn xác minh chữ ký HMAC (HS256/384/512). Mọi thứ đều ở lại trong trình duyệt của bạn.
Cách sử dụng Trình giải mã JWT
- 1
Dán token của bạn
Dán một JSON Web Token đã mã hóa vào ô nhập. Trình giải mã sẽ tự động tách nó thành header, payload và chữ ký.
- 2
Đọc các claim
Xem phần header và payload đã giải mã ở dạng JSON được định dạng, và xem lại các claim đã đăng ký như thời điểm hết hạn và thời điểm phát hành được hiển thị dưới dạng ngày giờ dễ đọc.
- 3
Xác minh chữ ký
Với các token HMAC, nhập khóa bí mật ký để xác nhận chữ ký hợp lệ và token chưa bị giả mạo.
- 4
Sao chép thứ bạn cần
Sao chép JSON header hoặc payload đã định dạng vào khay nhớ tạm để dùng khi kiểm thử, viết tài liệu hoặc gỡ lỗi.
Hiểu về JSON Web Token: Cấu trúc, các Claim và những Cạm bẫy
Ba phần ngăn cách bằng dấu chấm
Một JSON Web Token là một chuỗi dài duy nhất có hai dấu chấm bên trong, chia nó thành ba phân đoạn: header, payload và chữ ký. Mỗi phân đoạn trong hai phân đoạn đầu là một đối tượng JSON nhỏ đã được mã hóa Base64URL — một biến thể an toàn cho URL của Base64 vốn thay vài ký tự và bỏ phần đệm để token di chuyển trơn tru trong các header và chuỗi truy vấn. Phân đoạn thứ ba là chữ ký, được tính trên hai phân đoạn đầu.
Khi bạn dán một token vào, trình giải mã tách nó tại các dấu chấm và giải mã Base64URL hai phần đầu trở lại thành JSON dễ đọc. Bạn thấy phần header và payload đúng y như bên phát hành đã viết. Lý do điều này có thể làm được chính là mấu chốt của mọi thứ tiếp theo: các phân đoạn này chỉ được mã hóa chứ không hề được mật mã hóa.
Phần header: thuật toán và loại
Header là phần nhỏ nhất. Nó thường khai báo loại — JWT — và quan trọng hơn là thuật toán ký trong trường alg của nó. Các giá trị phổ biến là HS256, vốn dùng HMAC với một khóa bí mật dùng chung, và RS256 hay ES256, vốn dùng cặp khóa bất đối xứng trong đó một khóa riêng tư ký và một khóa công khai xác minh. Thuật toán cho bên xác minh biết chữ ký được tạo ra như thế nào và do đó phải kiểm tra nó ra sao.
Trường alg cũng liên quan đến bảo mật. Một token khai báo thuật toán là none, hoặc kẻ tấn công đổi token từ thuật toán bất đối xứng sang đối xứng để lừa một bên xác minh ngây thơ dùng khóa công khai làm khóa bí mật HMAC, là những cuộc tấn công kinh điển. Một bên xác minh đúng đắn sẽ cố định thuật toán mong đợi thay vì tin tưởng mù quáng vào bất cứ điều gì header nói.
Phần payload và các registered claim của nó
Payload mang theo các claim — những điều mà token tuyên bố. Một tập hợp các tên registered claim đã được chuẩn hóa để các hệ thống khác nhau thống nhất về ý nghĩa của chúng. Claim issuer (iss) cho biết ai đã tạo token, claim subject (sub) xác định nó nói về ai hoặc cái gì (thường là một ID người dùng), và claim audience (aud) cho biết người nhận dự kiến. Bên cạnh những claim này, bạn thường gặp các claim ứng dụng tùy chỉnh như một vai trò hay một tenant.
Trình giải mã này phơi bày các registered claim ở dạng có nhãn, dễ đọc cho con người để bạn không phải nhớ thuộc lòng những tên viết tắt khó hiểu. Nhìn thấy issuer, subject và audience được ghi rõ thường là tất cả những gì bạn cần khi đang lướt mắt qua một token trong lúc gỡ lỗi để xác nhận đó đúng là token phù hợp cho đúng dịch vụ.
Các claim thời gian: exp, iat và nbf
Ba claim chi phối vòng đời của một token, và tất cả đều là Unix timestamp tính bằng giây — không phải mili-giây, vốn là một lỗi sai lệch gấp nghìn lần thường gặp với các lập trình viên JavaScript quen dùng thời gian theo mili-giây. Claim hết hạn (exp) là thời điểm sau đó token phải bị từ chối, claim phát hành (iat) ghi lại lúc nó được tạo, và claim not-before (nbf) đánh dấu thời điểm sớm nhất nó trở nên hợp lệ.
Trình giải mã chuyển các claim này thành ngày giờ dễ đọc và cho bạn biết token hiện đang hoạt động, chưa có hiệu lực hay đã hết hạn theo đồng hồ trên thiết bị của bạn. Chi tiết cuối cùng đó rất quan trọng: nếu đồng hồ máy tính của bạn sai, kết luận đang-hoạt-động-hay-đã-hết-hạn có thể gây hiểu lầm, và trong môi trường production, lệch đồng hồ giữa các máy chủ là một lý do thường gặp khiến một token vừa phát hành bị từ chối vì chưa-có-hiệu-lực.
Giải mã không phải là xác minh
Đây là điều quan trọng nhất cần thấm nhuần. Bất kỳ ai cũng có thể giải mã một JWT — nó chỉ là Base64URL — nên việc đọc các claim cho bạn biết token nói gì, chứ không phải token có chính danh hay không. Sự tin cậy chỉ đến từ việc kiểm tra chữ ký dựa trên khóa, vốn chứng minh token đã được phát hành bởi một bên nắm giữ khóa bí mật hoặc khóa riêng tư và chưa bị thay đổi kể từ đó.
Với các token HMAC (HS256, HS384, HS512) công cụ này có thể tính lại chữ ký từ header, payload và khóa bí mật bạn cung cấp rồi so sánh với chữ ký của token, qua đó xác nhận tính xác thực đối với khóa bí mật đó. Các thuật toán bất đối xứng như RS256 và ES256 cần khóa công khai của bên phát hành nên ở đây chỉ được giải mã chứ không được xác minh. Điều cốt yếu là các quyết định phân quyền thực sự phải xác minh chữ ký phía máy chủ; không bao giờ tin tưởng các claim của một token chỉ dựa trên việc giải mã trong mã phía máy khách.
Payload không phải là bí mật
Vì payload chỉ được mã hóa, mọi claim bên trong nó hoàn toàn hiển thị với bất kỳ ai có được token — trình duyệt, bất kỳ proxy nào, hay chính người dùng. JWT là một nơi tuyệt vời cho dữ liệu định danh và phân quyền không nhạy cảm, và là một nơi tồi tệ cho bất cứ điều gì cần bảo mật. Đừng bao giờ đặt mật khẩu, khóa bí mật API, số thẻ tín dụng hay dữ liệu cá nhân riêng tư vào payload mà nghĩ rằng việc mã hóa bảo vệ chúng. Nó không hề bảo vệ.
Chữ ký bảo vệ tính toàn vẹn chứ không phải tính bảo mật: nó ngăn việc giả mạo, nhưng không làm gì để che giấu nội dung. Nếu bạn thực sự cần một token được mật mã hóa mà payload không thể đọc được, đó là một cấu trúc khác, nặng nề hơn (JWE) — một JWT tiêu chuẩn được ký chứ không được mật mã hóa. Hãy giữ các bí mật trên máy chủ và tham chiếu chúng bằng một định danh không hé lộ thông tin trong token thay vì đặt trực tiếp.
Gỡ lỗi token một cách an toàn
Trong công việc hằng ngày, trình giải mã tỏa sáng khi gỡ lỗi các luồng xác thực: xác nhận đúng người dùng nằm trong claim subject, kiểm tra audience có khớp với dịch vụ đang từ chối yêu cầu hay không, xác minh các scope hoặc vai trò có hiện diện, và đọc thời điểm hết hạn để xem một lỗi 401 có đơn giản chỉ là token đã cũ hay không. Sao chép phần header hoặc payload đã định dạng vào một báo cáo lỗi hay một test fixture chỉ là một thao tác một cú nhấp.
Mọi thứ diễn ra cục bộ trong trình duyệt của bạn — token và bất kỳ khóa bí mật nào bạn gõ đều không bao giờ bị tải lên, ghi lại hay lưu trữ — nên có thể yên tâm kiểm tra cả token production thực. Dù vậy, hãy đối xử với token như chính những thông tin đăng nhập mà chúng là: một token hợp lệ, chưa hết hạn là một chiếc chìa khóa sống vào một tài khoản, nên tránh dán nó vào các công cụ không đáng tin, và ưu tiên token đã hết hạn hoặc token thử nghiệm khi chia sẻ ví dụ.
Câu hỏi thường gặp
JSON Web Token (JWT) là gì?
Việc giải mã JWT có để lộ mật khẩu hay khóa bí mật không?
Việc xác minh chữ ký ở đây hoạt động như thế nào?
Các claim exp và iat có ý nghĩa gì?
Token của tôi có được gửi đến máy chủ không?
Công cụ liên quan
Tiếp tục với những công cụ hữu ích này