Giải mã JWT

Giải mã và kiểm tra JSON Web Token

Thử ví dụ

Token JWT

Chạy cục bộ · An toàn để dán thông tin bí mật
Thử thêm:Bộ mã hóa JWT

JWT (JSON Web Token) là gì?

JSON Web Token (JWT) là định dạng token nhỏ gọn, an toàn cho URL, được định nghĩa trong RFC 7519. Nó mã hóa một tập hợp các claim dưới dạng đối tượng JSON, sau đó ký — và tùy chọn mã hóa — để người nhận có thể xác minh dữ liệu không bị giả mạo. JWT là tiêu chuẩn thực tế cho xác thực không trạng thái trong REST API, hệ thống đăng nhập một lần và phân quyền microservice.

Cấu trúc JWT: Header · Payload · Signature

Mỗi JWT gồm ba đoạn mã hóa base64url ngăn cách bởi dấu chấm. Header và Payload là JSON thuần — ai cũng có thể đọc — trong khi Signature là giá trị mật mã chỉ có thể xác minh bằng khóa đúng.

Token đã mã hóa

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HeaderPayloadSignature
Header
json
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
json
{
  "sub":  "user123",
  "name": "Alice",
  "role": "admin",
  "iat":  1717200000,
  "exp":  1717203600
}

Tại sao dùng JWT Decoder?

JWT thô trông như văn bản ngẫu nhiên. Công cụ này hiển thị ngay Header và Payload dưới dạng JSON có định dạng để bạn kiểm tra các claim, xem thời hạn hết hạn và kiểm tra lựa chọn thuật toán mà không cần viết một dòng code nào.

🔍
Kiểm tra Claim tức thì
Xem từng claim trong Payload — sub, iss, aud, exp, vai trò tùy chỉnh, quyền — được định dạng và dễ đọc chỉ bằng một cú nhấp.
🔓
Không cần khóa bí mật
Header và Payload là công khai; chỉ Signature mới cần bí mật. Công cụ này giải mã cả hai mà không cần khóa ký của bạn.
⏱️
Phân tích thời hạn và dấu thời gian
Dấu thời gian Unix (exp, iat, nbf) được tự động chuyển đổi sang ngày dễ đọc để bạn có thể kiểm tra ngay liệu token có hết hạn chưa.
🔒
Chạy hoàn toàn trong trình duyệt
Mọi thứ được xử lý cục bộ — không có dữ liệu token nào được gửi đến bất kỳ máy chủ nào. An toàn khi dùng với token sản xuất trong quá trình gỡ lỗi.

Tham chiếu các Claim JWT chuẩn

RFC 7519 định nghĩa bảy tên claim đã đăng ký. Chúng không bắt buộc, nhưng việc sử dụng được khuyến nghị mạnh mẽ để đảm bảo khả năng tương tác. Bạn có thể thêm bất kỳ claim tùy chỉnh nào vào Payload.

ClaimMô tảKiểu
issNgười phát hànhXác định ai đã phát hành token — ví dụ URL máy chủ xác thực hoặc tên ứng dụng của bạn.string
subChủ thểXác định đối tượng mà JWT đề cập — thường là ID người dùng hoặc tài khoản dịch vụ.string
audĐối tượngXác định người nhận dự định. Bên nhận phải xác minh rằng điều này khớp với định danh của họ.string | string[]
expThời gian hết hạnDấu thời gian Unix sau đó token không được chấp nhận. Luôn đặt giá trị này để hạn chế thiệt hại từ token bị đánh cắp.number
nbfKhông trướcDấu thời gian Unix trước đó token không được chấp nhận. Hữu ích để lên lịch các token có ngày trong tương lai.number
iatĐược phát hành lúcDấu thời gian Unix khi token được phát hành. Dùng để tính tuổi của token.number
jtiJWT IDĐịnh danh duy nhất cho token. Cho phép thu hồi bằng cách lưu trữ và kiểm tra các giá trị JTI đã dùng ở phía máy chủ.string

Thuật toán ký JWT

Claim header alg khai báo thuật toán nào đã ký token. Lựa chọn ảnh hưởng đến bảo mật, hiệu suất và liệu các dịch vụ bên thứ ba có thể xác minh token mà không cần khóa riêng tư hay không.

Thuật toánHọ thuật toánLoại khóaGhi chú
HS256HMACSymmetricPhổ biến nhất. Bí mật chung — bất kỳ ai có bí mật đều có thể ký và xác minh.
HS384HMACSymmetricBiến thể HMAC mạnh hơn; chi phí hiệu suất vừa phải.
HS512HMACSymmetricBiến thể HMAC mạnh nhất.
RS256RSAAsymmetricThuật toán bất đối xứng được dùng rộng rãi nhất (Google, Auth0, Okta). Khóa công khai xác minh mà không cần khóa riêng.
RS384RSAAsymmetricBiến thể RS bảo mật cao hơn.
RS512RSAAsymmetricBiến thể RS mạnh nhất.
ES256ECDSAAsymmetricĐường cong elliptic — chữ ký ngắn hơn RSA, phổ biến trên thiết bị di động và IoT.
PS256RSA-PSSAsymmetricRSA-PSS: hiện đại và an toàn hơn RS256 dựa trên PKCS1v1.5.
noneKhông có chữ ký — cực kỳ nguy hiểm. Không bao giờ chấp nhận token với alg: none trong môi trường sản xuất.

Cân nhắc về bảo mật

Giải mã JWT luôn an toàn. Tin tưởng JWT mà không xác minh chữ ký đúng cách thì không an toàn. Hãy ghi nhớ những quy tắc này mỗi khi bạn dùng token trong ứng dụng của mình.

Luôn an toàn
  • Giải mã và kiểm tra JWT trong công cụ dành cho nhà phát triển hoặc công cụ này
  • Dùng exp, iat và nbf để hiểu thời hạn sống của token
  • Ghi nhật ký các claim Payload để gỡ lỗi (bỏ qua thông tin cá nhân nhạy cảm)
  • Đọc header alg để hiểu cách token được ký
Không bao giờ làm điều này
  • Tin tưởng các claim trong Payload mà không xác minh chữ ký phía máy chủ
  • Chấp nhận token với alg: none — điều này có nghĩa là không có chữ ký nào cả
  • Lưu trữ token truy cập trong localStorage trên các ứng dụng có bảo mật cao (ưu tiên cookie httpOnly)
  • Đặt exp quá xa trong tương lai cho các token mang quyền nhạy cảm

Các trường hợp sử dụng phổ biến

Gỡ lỗi luồng xác thực
Dán token từ tab mạng của trình duyệt để kiểm tra claim, xem các vai trò nhúng và xác minh thời hạn mà không cần chạm vào code sản xuất.
Kiểm tra token từ bên thứ ba
Đọc nhanh token từ Google, Auth0, Okta hoặc Azure AD để xem nhà cung cấp của bạn bao gồm những claim nào và so sánh với schema mong đợi.
Phát triển và kiểm thử API
Khi viết hoặc kiểm thử các endpoint API, giải mã header ủy quyền để xác nhận logic tạo token của bạn đặt đúng giá trị sub, aud và scope.
Phân quyền Microservice
Trong service mesh, mỗi dịch vụ xác thực JWT từ caller upstream. Giải mã token để theo dõi dịch vụ nào đã phát hành token và nó khẳng định quyền gì.
Hỗ trợ và ứng phó sự cố
Khi người dùng báo cáo lỗi xác thực, giải mã token của họ để kiểm tra xem có hết hạn không, audience có sai không, hoặc thiếu claim bắt buộc không.
Kiểm toán bảo mật
Kiểm toán việc sử dụng JWT trên các dịch vụ bằng cách kiểm tra lựa chọn thuật toán, cửa sổ hết hạn và liệu dữ liệu nhạy cảm có vô tình được lưu trữ trong Payload không mã hóa hay không.

Giải mã JWT trong code

Header và Payload được mã hóa base64url — chỉ cần đảo ngược mã hóa. Base64url thay + bằng - và / bằng _, và bỏ qua ký tự đệm =. Chỉ Signature mới cần khóa bí mật.

JavaScript (browser)
function decodeJWT(token) {
  const [, payload] = token.split('.')
  const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
  return JSON.parse(json)
}
Node.js
const [, payload] = token.split('.')
const decoded = JSON.parse(
  Buffer.from(payload, 'base64url').toString()
)
Python
import base64, json

def decode_jwt(token):
    payload = token.split('.')[1]
    padding = '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload + padding))
CLI (bash + jq)
TOKEN="eyJhbGc..."
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .

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

Tôi có thể giải mã JWT mà không cần khóa bí mật không?
Có. Header và Payload của JWT chỉ là JSON được mã hóa base64url — không phải mã hóa. Bất kỳ ai cũng có thể giải mã và đọc chúng. Bí mật (hoặc khóa riêng tư cho các thuật toán RS/ES) chỉ cần thiết để xác minh chữ ký, xác nhận token không bị giả mạo.
Giải mã JWT có nghĩa là chữ ký đã được xác minh không?
Không. Giải mã chỉ đọc các claim. Xác minh là một bước riêng kiểm tra chữ ký mật mã bằng khóa đúng. Luôn xác minh chữ ký trước khi tin tưởng bất kỳ claim nào trong ứng dụng của bạn.
Sự khác biệt giữa HS256 và RS256 là gì?
HS256 sử dụng một bí mật đối xứng duy nhất được chia sẻ giữa người phát hành và người xác minh — bất kỳ ai có bí mật đều có thể tạo và xác minh token. RS256 sử dụng cặp khóa bất đối xứng: khóa riêng ký, khóa công khai xác minh. Với RS256 bạn có thể phân phối khóa công khai để các dịch vụ bên ngoài có thể xác minh token mà không có khả năng giả mạo chúng.
Tại sao giải mã base64 đôi khi thất bại?
JWT sử dụng mã hóa base64url, dùng - thay cho + và _ thay cho /, và bỏ qua ký tự đệm =. Các bộ giải mã base64 tiêu chuẩn yêu cầu + và / và có thể cần đệm. Thêm đệm (đệm đến bội số của 4 bằng =) và hoán đổi ký tự trước khi giải mã thủ công.
Dán JWT sản xuất vào công cụ này có an toàn không?
Có — công cụ này chạy hoàn toàn trong trình duyệt của bạn và không gửi dữ liệu đến bất kỳ máy chủ nào. Tuy nhiên, hãy chú ý đến ai có thể nhìn thấy màn hình hoặc lịch sử trình duyệt của bạn. Đối với các token cực kỳ nhạy cảm, hãy giải mã chúng cục bộ trong terminal.
alg: none có nghĩa là gì và có nguy hiểm không?
alg: none có nghĩa là token không có chữ ký mật mã — bất kỳ ai cũng có thể tạo token với các claim tùy ý và đặt alg thành none. Một số thư viện JWT đời đầu chấp nhận các token này, tạo ra lỗ hổng nghiêm trọng. Thư viện JWT an toàn luôn từ chối các token với alg: none trừ khi được cấu hình rõ ràng. Không bao giờ tắt kiểm tra này.