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 (JSON Web Token) là gì?

JWT (JSON Web Token) là một chuẩn mở (RFC 7519) để truyền thông tin an toàn giữa các bên dưới dạng đối tượng JSON. Đây là định dạng token nhỏ gọn, an toàn với URL và được ký số để xác minh tính xác thực và toàn vẹn.

Cấu trúc JWT:
Một JWT bao gồm ba phần được phân tách bằng dấu chấm (.): header.payload.signature

1. Header (JOSE Header):
- Chứa metadata của token
- Xác định thuật toán ký (ví dụ: HS256, RS256, ES256)
- Định nghĩa loại token (thường là "JWT")
- Ví dụ: {"alg":"HS256","typ":"JWT"}

2. Payload (Claims):
- Chứa dữ liệu thực tế (claims)
- Bao gồm registered claims (iss, exp, sub, aud, v.v.)
- Có thể bao gồm custom claims (user ID, roles, permissions, v.v.)
- Ví dụ: {"sub":"1234567890","name":"Nguyễn Văn A","iat":1516239022}

3. Signature (Chữ ký):
- Xác minh token không bị thay đổi
- Được tạo bằng cách mã hóa header và payload, sau đó ký bằng secret key
- Các thuật toán khác nhau sử dụng phương pháp ký khác nhau

Ứng dụng phổ biến:
- Xác thực: Phiên đăng nhập người dùng
- Ủy quyền: Kiểm soát truy cập và phân quyền
- Trao đổi thông tin: Truyền dữ liệu an toàn
- Bảo mật API: Xác thực không trạng thái cho REST APIs
- Single Sign-On (SSO): Xác thực xuyên domain
- OAuth 2.0 & OpenID Connect: Ủy quyền dựa trên token

JWT được mã hóa base64url (không được mã hóa bảo mật), có nghĩa là bất kỳ ai cũng có thể giải mã và đọc nội dung. Chữ ký đảm bảo token không bị sửa đổi, nhưng không mã hóa dữ liệu. Không bao giờ đặt thông tin nhạy cảm như mật khẩu hoặc số thẻ tín dụng trong JWT payload.

Làm thế nào để giải mã JWT token?

Giải mã JWT token rất đơn giản với công cụ này:

1. Sao chép JWT token của bạn (chuỗi dài bắt đầu bằng eyJ...)
2. Dán vào trường nhập "JWT Token"
3. Nhấp vào nút "Giải mã JWT"
4. Xem kết quả đã giải mã:
- Header: Hiển thị thuật toán và loại token
- Payload: Hiển thị tất cả claims (dữ liệu)
- Signature: Hiển thị phần chữ ký (base64url encoded)
- Standard Claims: Giải thích dễ hiểu các claims phổ biến
- Token Info: Thuật toán, loại và trạng thái hết hạn

Ví dụ JWT:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ik5ndXnhu4VuIFbEg24gQSIsImlhdCI6MTUxNjIzOTAyMn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header đã giải mã:
{
"alg": "HS256",
"typ": "JWT"
}

Payload đã giải mã:
{
"sub": "1234567890",
"name": "Nguyễn Văn A",
"iat": 1516239022
}

Công cụ tự động:
- Xác thực định dạng JWT (3 phần phân tách bằng dấu chấm)
- Giải mã base64url header và payload
- Phân tích cấu trúc JSON
- Định dạng output để dễ đọc
- Nhận diện và giải thích các claims chuẩn
- Kiểm tra trạng thái hết hạn token
- Hiển thị timestamp dễ đọc cho các date claims

JWT claims là gì?

JWT claims là các câu lệnh hoặc thông tin chứa trong phần payload của JWT token. Claims là các cặp tên-giá trị đại diện cho dữ liệu về người dùng hoặc bản thân token.

Các loại Claims:

1. Registered Claims (Claims chuẩn/dành riêng):
Đây là các claims được định nghĩa trước theo đặc tả JWT:

- iss (Issuer/Người phát hành): Ai tạo và ký token
Ví dụ: "iss": "https://auth.example.com"

- sub (Subject/Chủ thể): Chủ thể chính của token (thường là user ID)
Ví dụ: "sub": "1234567890" hoặc "sub": "[email protected]"

- aud (Audience/Đối tượng): Token được dự định cho ai (người nhận)
Ví dụ: "aud": "https://api.example.com"

- exp (Expiration Time/Thời gian hết hạn): Khi nào token hết hạn (Unix timestamp)
Ví dụ: "exp": 1735689600 (phải từ chối token sau thời gian này)

- nbf (Not Before/Không dùng trước): Token không hợp lệ trước thời gian này (Unix timestamp)
Ví dụ: "nbf": 1735603200

- iat (Issued At/Thời gian phát hành): Khi token được tạo (Unix timestamp)
Ví dụ: "iat": 1735603200

- jti (JWT ID): Định danh duy nhất cho token
Ví dụ: "jti": "abc123xyz" (ngăn chặn replay attacks)

2. Public Claims:
Các claims tùy chỉnh nên được đăng ký trong IANA JWT Registry hoặc sử dụng tên chống xung đột:
Ví dụ: "email": "[email protected]", "email_verified": true

3. Private Claims:
Các claims tùy chỉnh được thỏa thuận giữa các bên:
Ví dụ: "role": "admin", "permissions": ["read", "write"], "phong_ban": "CNTT"

Thực hành tốt nhất:
- Giữ payload nhỏ gọn (JWT được gửi trong mỗi request)
- Không bao gồm dữ liệu nhạy cảm (JWT có thể đọc được bởi bất kỳ ai)
- Luôn bao gồm claim 'exp' để giới hạn thời gian sống của token
- Sử dụng 'iat' để theo dõi khi token được phát hành
- Sử dụng 'jti' cho cơ chế thu hồi token
- Xác thực tất cả claims ở phía server

Ví dụ Payload với nhiều Claims:
{
"iss": "https://auth.example.com",
"sub": "user123",
"aud": "https://api.example.com",
"exp": 1735689600,
"iat": 1735603200,
"name": "Nguyễn Văn A",
"email": "[email protected]",
"role": "admin",
"permissions": ["read", "write", "delete"]
}

Làm thế nào để xác thực chữ ký JWT?

Xác thực chữ ký JWT là bước bảo mật quan trọng đảm bảo token không bị thay đổi. Tuy nhiên, việc xác thực chữ ký PHẢI được thực hiện ở phía server, không phải trong trình duyệt.

Tại sao chỉ ở phía Server?
- Yêu cầu secret key (thuật toán đối xứng) hoặc private key (thuật toán bất đối xứng)
- Để lộ key trong code phía client sẽ làm mất bảo mật
- Bất kỳ ai cũng có thể sửa đổi token nếu key công khai
- Xác thực trong JavaScript trình duyệt KHÔNG an toàn

Quy trình xác thực chữ ký:

1. Với Thuật toán Đối xứng (HS256, HS384, HS512):
- Server có secret key
- Lấy header + payload từ JWT
- Ký chúng bằng secret key sử dụng thuật toán được chỉ định
- So sánh chữ ký kết quả với chữ ký của JWT
- Nếu khớp, token hợp lệ và không bị sửa đổi

2. Với Thuật toán Bất đối xứng (RS256, RS384, RS512, ES256, ES384, ES512):
- Token được ký bằng private key
- Server xác thực bằng public key tương ứng
- Public key có thể chia sẻ an toàn
- Chỉ người có private key mới có thể tạo chữ ký hợp lệ

Xác thực phía Server (Ví dụ khái niệm):

Node.js (thư viện jsonwebtoken):
const jwt = require('jsonwebtoken');
try {
const decoded = jwt.verify(token, secretKey);
// Token hợp lệ
} catch (error) {
// Token không hợp lệ hoặc hết hạn
}

Python (thư viện PyJWT):
import jwt
try:
decoded = jwt.decode(token, secret_key, algorithms=["HS256"])
# Token hợp lệ
except jwt.InvalidTokenError:
# Token không hợp lệ hoặc hết hạn

Công cụ này làm gì:
- Giải mã cấu trúc JWT (header, payload, signature)
- Hiển thị claims và metadata
- Hiển thị thuật toán nào được sử dụng
- Kiểm tra trạng thái hết hạn
- KHÔNG xác thực chữ ký (không có secret key)

Lưu ý Bảo mật Quan trọng:
- KHÔNG BAO GIỜ chia sẻ secret keys hoặc private keys
- KHÔNG BAO GIỜ xác thực chữ ký trong JavaScript phía client
- Luôn xác thực chữ ký trên backend server của bạn
- Sử dụng HTTPS để truyền JWT tokens
- Lưu trữ JWT an toàn (httpOnly cookies hoặc secure storage)
- Triển khai cơ chế hết hạn và làm mới token
- Sử dụng secret keys mạnh (ít nhất 256 bits cho HS256)

Công cụ giải mã này dùng để:
✓ Kiểm tra cấu trúc JWT
✓ Debug các vấn đề xác thực
✓ Hiểu claims và metadata
✓ Kiểm tra hết hạn token
✓ Mục đích giáo dục

KHÔNG dùng để:
✗ Xác thực chữ ký production
✗ Xác thực bảo mật
✗ Quyết định tin cậy

Các thuật toán JWT khác nhau là gì?

JWT hỗ trợ nhiều thuật toán mật mã để ký tokens, được chia thành hai loại chính:

1. HMAC (Thuật toán Đối xứng):
Sử dụng cùng một secret key cho cả ký và xác thực.

- HS256 (HMAC SHA-256):
* Được sử dụng phổ biến nhất
* Nhanh và hiệu quả
* Khuyến nghị secret key 256-bit
* Tốt cho xác thực server-to-server
* Cả hai bên phải chia sẻ secret key an toàn

- HS384 (HMAC SHA-384):
* Mạnh hơn HS256
* Hash 384-bit
* Chữ ký hơi lớn hơn

- HS512 (HMAC SHA-512):
* Tùy chọn HMAC mạnh nhất
* Hash 512-bit
* Kích thước chữ ký lớn nhất

Khi nào dùng HMAC:
- APIs nội bộ và microservices
- Giao tiếp server-to-server
- Khi cả hai bên có thể chia sẻ secret an toàn
- Khi hiệu suất là quan trọng
- Quản lý key đơn giản hơn

2. RSA (Thuật toán Bất đối xứng):
Sử dụng cặp public-private key. Ký bằng private key, xác thực bằng public key.

- RS256 (RSA SHA-256):
* Rất phổ biến cho public APIs
* Public key có thể chia sẻ an toàn
* Kích thước chữ ký lớn hơn HMAC
* Chậm hơn HMAC

- RS384 (RSA SHA-384):
* Mạnh hơn RS256
* Keys và chữ ký lớn hơn

- RS512 (RSA SHA-512):
* Tùy chọn RSA mạnh nhất
* Overhead lớn nhất

Khi nào dùng RSA:
- Public APIs (OAuth 2.0, OpenID Connect)
- Nhiều người tiêu dùng cần xác thực tokens
- Khi cần phân phối public key
- Tích hợp bên thứ ba
- Yêu cầu bảo mật cao hơn

3. ECDSA (Elliptic Curve - Bất đối xứng):
Sử dụng mật mã đường cong elliptic. Keys nhỏ hơn RSA với bảo mật tương tự.

- ES256 (ECDSA P-256 SHA-256):
* Hiện đại và hiệu quả
* Chữ ký nhỏ hơn RSA
* Bảo mật tương tự RSA với keys nhỏ hơn
* Ngày càng phổ biến

- ES384 (ECDSA P-384 SHA-384):
* Mạnh hơn ES256
* Cân bằng tốt giữa bảo mật và hiệu suất

- ES512 (ECDSA P-521 SHA-512):
* Bảo mật ECDSA cao nhất
* Lưu ý: Đường cong P-521 (không phải P-512)

Khi nào dùng ECDSA:
- Ứng dụng mobile (chữ ký nhỏ hơn)
- Thiết bị IoT (mật mã hiệu quả)
- Hệ thống hiện đại có hỗ trợ ECDSA
- Khi băng thông bị hạn chế

So sánh Thuật toán:

Bảo mật (Mạnh nhất đến Yếu nhất):
ES512 > RS512 > PS512 > ES384 > RS384 > ES256 > RS256 > PS256 > HS512 > HS384 > HS256

Hiệu suất (Nhanh nhất đến Chậm nhất):
HS256 > HS384 > HS512 > ES256 > ES384 > ES512 > RS256 > RS384 > RS512

Kích thước Chữ ký (Nhỏ nhất đến Lớn nhất):
ES256 < HS256 < ES384 < HS384 < ES512 < HS512 < RS256 < RS384 < RS512

Cảnh báo Thuật toán None:
- "alg": "none" có nghĩa là không có chữ ký
- KHÔNG BAO GIỜ chấp nhận unsigned tokens trong production
- Lỗ hổng bảo mật nghiêm trọng
- Luôn xác thực thuật toán

Khuyến nghị:
- Lựa chọn mặc định: RS256 hoặc ES256 cho public APIs
- Dịch vụ nội bộ: HS256 cho sự đơn giản và tốc độ
- Mobile/IoT: ES256 cho hiệu quả
- Bảo mật tối đa: ES512 hoặc RS512
- Hệ thống hiện đại: Xem xét EdDSA nếu được hỗ trợ

JWT có an toàn không? Những vấn đề bảo mật cần lưu ý là gì?

JWT có thể an toàn khi được sử dụng đúng cách, nhưng có những vấn đề bảo mật quan trọng và lỗ hổng tiềm ẩn cần lưu ý:

Điểm mạnh về Bảo mật:
✓ Chống giả mạo: Chữ ký ngăn chặn sửa đổi
✓ Không trạng thái: Không cần lưu trữ session phía server
✓ Di động: Hoạt động xuyên domain và dịch vụ
✓ Chuẩn hóa: Đặc tả được định nghĩa rõ ràng (RFC 7519)
✓ Linh hoạt: Hỗ trợ nhiều thuật toán

Các vấn đề Bảo mật & Thực hành Tốt nhất:

1. JWT KHÔNG được Mã hóa (mặc định):
- Bất kỳ ai cũng có thể giải mã và đọc payload
- Không bao giờ lưu dữ liệu nhạy cảm trong JWT (mật khẩu, thẻ tín dụng, số CMND)
- Xem xét JWE (JSON Web Encryption) cho tokens được mã hóa
- Sử dụng HTTPS để truyền JWT tokens

2. Bảo mật Secret Key:
- Sử dụng secret keys mạnh, ngẫu nhiên (256+ bits cho HS256)
- Không bao giờ commit keys vào version control
- Xoay vòng keys định kỳ
- Sử dụng biến môi trường hoặc hệ thống quản lý key
- Keys khác nhau cho môi trường khác nhau

3. Tấn công Nhầm lẫn Thuật toán:
- Luôn xác thực thuật toán ở server
- Từ chối tokens với "alg": "none"
- Không để token quyết định thuật toán nào được sử dụng
- Chỉ định rõ ràng các thuật toán được phép

4. Hết hạn Token:
- Luôn bao gồm claim 'exp'
- Sử dụng thời gian hết hạn ngắn (15-60 phút)
- Triển khai refresh tokens cho phiên dài hạn
- Kiểm tra hết hạn trên mỗi request

5. Lưu trữ Token:
- Trình duyệt: httpOnly + Secure cookies (tốt nhất cho web)
- Mobile: Secure storage (Keychain, KeyStore)
- Không bao giờ lưu trong localStorage (dễ bị tấn công XSS)
- Không bao giờ lưu trong cookies thường không có cờ httpOnly

6. Thu hồi Token:
- JWT là stateless (không thể thu hồi mặc định)
- Triển khai danh sách đen token cho tokens bị thu hồi
- Sử dụng hết hạn ngắn + refresh tokens
- Xem xét JTI (JWT ID) claim để theo dõi
- Duy trì danh sách các JTIs bị thu hồi trong Redis/database

7. Tấn công Cross-Site:
- XSS (Cross-Site Scripting): Có thể đánh cắp tokens từ localStorage
- CSRF (Cross-Site Request Forgery): Sử dụng thuộc tính SameSite cookie
- Sử dụng Content Security Policy (CSP) headers
- Làm sạch đầu vào người dùng

8. Tấn công Replay:
- Sử dụng JTI (JWT ID) claim với sử dụng một lần
- Theo dõi các tokens đã sử dụng
- Triển khai claim 'nbf' (not before)
- Sử dụng nonce cho các hoạt động quan trọng

Danh sách Kiểm tra Bảo mật:
☐ Sử dụng HTTPS cho tất cả truyền token
☐ Lưu trữ tokens trong httpOnly cookies (web) hoặc secure storage (mobile)
☐ Bao gồm claim 'exp' với thời gian hết hạn ngắn
☐ Xác thực chữ ký trên mỗi request
☐ Xác thực tất cả claims (iss, aud, exp, nbf)
☐ Sử dụng secret keys mạnh (256+ bits)
☐ Chỉ định rõ ràng các thuật toán được phép
☐ Không bao giờ lưu dữ liệu nhạy cảm trong JWT payload
☐ Triển khai cơ chế refresh token
☐ Có chiến lược thu hồi token
☐ Xoay vòng keys định kỳ
☐ Sử dụng thư viện JWT đã được thiết lập
☐ Giám sát việc sử dụng token đáng ngờ

JWT an toàn khi:
✓ Được sử dụng đúng cách với các thực hành tốt nhất
✓ Được truyền qua HTTPS
✓ Được lưu trữ an toàn
✓ Được xác thực đúng cách phía server
✓ Kết hợp với các biện pháp bảo mật khác

JWT KHÔNG an toàn khi:
✗ Chứa dữ liệu nhạy cảm
✗ Sử dụng keys yếu
✗ Lưu trữ trong localStorage (web)
✗ Được truyền qua HTTP
✗ Chữ ký không được xác thực
✗ Không đặt thời gian hết hạn
✗ Thuật toán không được xác thực

Dữ liệu JWT token của tôi có an toàn khi sử dụng công cụ giải mã này không?

Có, JWT token của bạn hoàn toàn an toàn và riêng tư khi sử dụng công cụ giải mã này. Đây là lý do:

Tính năng Riêng tư & Bảo mật:

✓ Xử lý 100% Phía Client:
- Tất cả giải mã diễn ra trong trình duyệt của bạn
- JavaScript chạy cục bộ trên máy tính của bạn
- Không có xử lý phía server
- Không có network requests

✓ Không Truyền Dữ liệu:
- JWT của bạn không bao giờ rời khỏi máy tính của bạn
- Không có dữ liệu được gửi đến bất kỳ server nào
- Không có API calls
- Không có dịch vụ bên ngoài

✓ Không Lưu trữ:
- Chúng tôi không lưu trữ bất kỳ tokens nào
- Không ghi log dữ liệu
- Không có cookies theo dõi tokens của bạn
- Không có analytics trên dữ liệu token

✓ Không Theo dõi:
- Chúng tôi không theo dõi tokens nào bạn giải mã
- Không có analytics trên dữ liệu đã giải mã
- Thiết kế tập trung vào quyền riêng tư

✓ Hoạt động Offline:
- Sau khi tải trang, hoạt động mà không cần internet
- Ngắt kết nối và nó vẫn hoạt động
- Chứng minh không có truyền dữ liệu

✓ Mã nguồn Mở:
- Mã có thể xem trong page source
- Bạn có thể xác minh implementation
- Hoạt động minh bạch

Cách Xác minh Quyền riêng tư:

1. Kiểm tra Network Tab:
- Mở DevTools trình duyệt (F12)
- Vào tab Network
- Giải mã một JWT token
- Quan sát: Không có network requests nào được thực hiện

2. Kiểm tra Offline:
- Tải trang này
- Ngắt kết nối internet
- Thử giải mã một token
- Nó vẫn hoạt động!

3. Xem xét Mã nguồn:
- Xem page source
- Kiểm tra mã JavaScript
- Xác minh không có external calls

Tuy nhiên, Lưu ý Quan trọng:

⚠️ JWT KHÔNG được Mã hóa:
- JWT payload được mã hóa Base64 (không phải mã hóa bảo mật)
- Bất kỳ ai có token đều có thể giải mã nó
- Không đặt dữ liệu nhạy cảm trong JWT payloads
- Điều này áp dụng cho TẤT CẢ các JWT decoders (không chỉ công cụ này)

⚠️ Bảo mật Trình duyệt:
- Giải mã diễn ra trong bộ nhớ trình duyệt
- Hãy thận trọng trên máy tính dùng chung
- Xóa cache trình duyệt sau khi sử dụng trên máy công cộng
- Sử dụng chế độ private/incognito cho tokens nhạy cảm

Thực hành Tốt nhất:

1. Development Tokens:
✓ An toàn để giải mã development tokens
✓ An toàn để giải mã test tokens
✓ An toàn để giải mã non-production tokens

2. Production Tokens:
⚠️ Hãy thận trọng với production tokens
⚠️ Xem xét độ nhạy cảm của dữ liệu
⚠️ Chỉ sử dụng trên thiết bị đáng tin cậy
⚠️ Xóa sau khi sử dụng

3. Sensitive Tokens:
✗ Tránh giải mã trên máy tính dùng chung
✗ Không giải mã khi đang chia sẻ màn hình
✗ Không chụp màn hình tokens

Kết luận:

Token của bạn an toàn với công cụ này vì tất cả xử lý là cục bộ. Tuy nhiên, hãy nhớ rằng JWT tokens được thiết kế để có thể đọc được bởi bất kỳ ai có chúng. Chữ ký đảm bảo chúng không thể bị sửa đổi, không phải là không thể đọc. Luôn tuân theo các thực hành tốt nhất về JWT và không bao giờ đặt dữ liệu thực sự nhạy cảm (mật khẩu, thẻ tín dụng, v.v.) trong JWT payloads.

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