Trình tạo JWT miễn phí

JWT Thực Chất Là Gì

JSON Web Token (JWT), phát âm là "jot", là một biểu diễn nhỏ gọn, an toàn-URL của các xác nhận quyền sở hữu (claim) cần được chuyển giữa hai bên. Định dạng là ba phân đoạn được mã hóa Base64url được phân tách bằng dấu chấm: header.payload.signature. Header khai báo loại token (luôn là JWT) và thuật toán ký (thường là HS256, RS256, hoặc ES256). Payload mang các claim: một đối tượng JSON với các trường chuẩn như iss (issuer), sub (subject), aud (audience), exp (thời gian hết hạn dưới dạng dấu thời gian Unix), nbf (not before), iat (issued at), jti (JWT ID), cộng với bất kỳ claim cụ thể-ứng dụng nào mà issuer muốn bao gồm. Signature là bằng chứng mật mã rằng header và payload chưa bị giả mạo: được tạo bằng cách ký chuỗi base64url(header).base64url(payload) được nối với thuật toán và khóa được khai báo trong header. JWT được Michael B. Jones, John Bradley, và Nat Sakimura đặc tả là RFC 7519 vào tháng 5 năm 2015, dựa trên công việc trước đó trong JOSE (JSON Object Signing and Encryption: RFC 7515 đến 7520). Định dạng đã trở thành hình dạng token chiếm ưu thế trong xác thực web hiện đại, được sử dụng bởi các triển khai OAuth 2.0 / OIDC, các API gateway, các token phiên ứng dụng single-page, xác thực giữa các microservice, và quản lý phiên dựa trên cookie trình duyệt ở quy mô lớn.

Lựa Chọn Thuật Toán Ký: HS256 vs RS256 vs ES256

JWT hỗ trợ một số thuật toán ký được đăng ký trong JOSE Algorithms registry (RFC 7518). HS256 (HMAC-SHA256) là đơn giản nhất: một thuật toán đối xứng trong đó cùng một bí mật được sử dụng để ký và xác minh. Rẻ để tính toán, dễ thực hiện, và phù hợp khi người ký và người xác minh là cùng một bên (ví dụ: một ứng dụng duy nhất phát hành các token phiên cho chính nó). RS256 (RSA-SHA256) là bất đối xứng: khóa riêng ký, khóa công khai xác minh. Được sử dụng khi issuer và verifier là các bên khác nhau: Auth0, Okta, Google Identity Platform, Microsoft Entra ID, và hầu hết các nhà cung cấp danh tính đám mây phát hành các JWT được ký RS256 vì các client có thể xác minh chữ ký bằng endpoint JWKS (JSON Web Key Set) được công bố mà không cần chia sẻ bí mật. ES256 (ECDSA P-256 SHA-256) là tương đương đường cong elliptic của RS256: cùng mô hình khóa công khai/riêng, khóa ngắn hơn nhiều (256 bit so với mức tối thiểu 2048 của RSA), xác minh nhanh hơn. EdDSA (Ed25519) là người kế nhiệm hiện đại của ES256, hơi nhanh hơn và với các thuộc tính mật mã sạch sẽ hơn; được hỗ trợ trong các thư viện JWT mới hơn nhưng chưa phổ biến. none là chế độ "không chữ ký" được phép theo đặc tả JWT đã gây ra các sự cố bảo mật trên nhiều thư viện khi các triển khai không từ chối các token alg: none: bài học là trình xác minh JWT phải kiểm tra rõ ràng thuật toán khớp với thuật toán mong đợi. Trình tạo này sử dụng HS256 vì nó chỉ yêu cầu một bí mật được chia sẻ thay vì tạo khóa; để sử dụng các thuật toán bất đối xứng trong sản xuất, một thư viện phía máy chủ là công cụ phù hợp.

Khi Nào Bạn Cần Tạo JWT Bằng Tay

• Kiểm thử các endpoint API. Một API yêu cầu JWT trong header Authorization: để kiểm thử thủ công với curl, Postman, hoặc HTTPie, bạn cần một token. Tạo một JWT thử nghiệm với hình dạng đúng, ký bằng bí mật được chia sẻ của API (trong môi trường dev), và sử dụng kết quả.
• Tái tạo lỗi liên quan đến token. Người dùng báo cáo vấn đề xác thực. Tái tạo token họ sẽ nhận được với các claim của họ, kiểm tra chữ ký, xác minh logic xác minh dịch vụ của bạn so với token được biết là tốt và được biết là xấu.
• Phát triển cục bộ không có nhà cung cấp xác thực. Xây dựng frontend đối với một API mong đợi xác thực JWT, nhưng bạn chưa có quyền truy cập vào nhà cung cấp danh tính sản xuất. Tạo các JWT thử nghiệm với các claim thực tế cho phát triển.
• Học định dạng JWT. Giải mã một JWT, thay đổi một claim, ký lại, xem ứng dụng của bạn làm gì. Vòng lặp gỡ lỗi-bằng-cách-thử-nghiệm thực hành là cách hầu hết các nhà phát triển hiểu cấu trúc JWT.
• Token giữa các dịch vụ nội bộ. Hai microservice nội bộ chia sẻ một bí mật và sử dụng JWT để xác thực các yêu cầu. Mô hình bí mật-được-chia-sẻ HS256 là phù hợp ở đây; công cụ này có thể tạo token thủ công để kiểm thử.

Bẫy Bảo Mật: Nơi JWT Sai Lầm

JWT có một lịch sử dài về các sai lầm triển khai đã tạo ra các sự cố bảo mật thực sự. Cuộc tấn công "alg: none": các thư viện JWT ban đầu chấp nhận các token với trường thuật toán được đặt thành "none" (không có chữ ký), cho phép kẻ tấn công giả mạo bất kỳ token nào. Người xác minh phải thực thi rõ ràng thuật toán mong đợi. Nhầm lẫn thuật toán: một người xác minh chấp nhận cả RS256 và HS256 có thể bị lừa bằng cách sử dụng khóa RSA công khai làm bí mật HMAC: kẻ tấn công ký bằng HS256 sử dụng khóa công khai, người xác minh (nhầm-)xác minh bằng HMAC sử dụng cùng khóa công khai đó. Người xác minh phải khóa thuật toán mong đợi. Dữ liệu nhạy cảm trong payload: các claim JWT được mã hóa Base64 nhưng không được mã hóa. Bất kỳ ai có token đều có thể đọc mọi claim. Không bao giờ đặt mật khẩu, số thẻ tín dụng đầy đủ, hoặc các bí mật khác trong payload. Không có hết hạn: JWT không có claim exp có hiệu lực mãi mãi. Luôn đặt một hết hạn hợp lý (phút cho token truy cập, ngày cho token làm mới). Không có thu hồi: JWT là tự-chứa: một khi đã phát hành, chúng vẫn có hiệu lực cho đến exp bất kể người dùng đăng xuất, thay đổi mật khẩu, hay tài khoản của họ bị đình chỉ. Hoặc chấp nhận hạn chế này, hoặc duy trì danh sách thu hồi (mà một phần đánh bại điểm token-không-trạng-thái), hoặc sử dụng các token truy cập có thời gian sống ngắn với xoay vòng token làm mới. Lưu trữ trong localStorage so với cookie: JWT trong localStorage có thể truy cập được bởi bất kỳ JavaScript nào chạy trên trang (rủi ro XSS); JWT trong cookie HttpOnly thì không (nhưng được gửi tự động với các yêu cầu cross-origin, rủi ro CSRF). Cả hai đều có sự đánh đổi; thực hành tốt nhất hiện đại có xu hướng nghiêng về cookie HttpOnly với các hạn chế SameSite cộng với token CSRF.

JWT vs Cookie Phiên vs PASETO

JWT không phải là lựa chọn duy nhất. Cookie phiên truyền thống lưu trữ một ID phiên không trong suốt; máy chủ giữ trạng thái phiên thực tế trong một cơ sở dữ liệu hoặc cache. Ưu điểm: thu hồi đơn giản (xóa bản ghi phía máy chủ), không có rủi ro rò rỉ dữ liệu claim, không có sự phức tạp chữ ký. Nhược điểm: yêu cầu tra cứu kho phiên trên mỗi yêu cầu (độ trễ), khó mở rộng giữa các dịch vụ hơn. PASETO (Platform-Agnostic Security Tokens, Scott Arciszewski 2018) là một thay thế JWT được thiết kế để tránh các bẫy nhầm-lẫn-thuật-toán và "none": định dạng có phiên bản, không thương lượng thuật toán, chữ ký bắt buộc, lựa chọn cipher hạn chế. PASETO đã thu hút sự quan tâm trong các bối cảnh nhạy cảm-bảo-mật nhưng chưa thay thế JWT trong hệ sinh thái rộng hơn. Macaroons (Google, 2014) là một định dạng token linh hoạt hơn với các hạn chế khả năng được nối nhưng về cơ bản chỉ là nghiên cứu vào năm 2026. OAuth 2.1 củng cố các thực hành tốt nhất OAuth 2.0: JWT vẫn là định dạng token truy cập điển hình. Lựa chọn thực dụng vào năm 2026 vẫn là JWT cho các microservice không-trạng-thái và các token API, các cookie phiên không trong suốt cho các ứng dụng web được render máy chủ truyền thống, với PASETO là lựa chọn thay thế hiện đại cho các dự án greenfield mới muốn các mặc định mạnh hơn.

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ó. Các phần header và payload của JWT chỉ được mã hóa Base64url, không được mã hóa bảo mật. Bạn có thể đọc tất cả claims mà không cần khóa bí mật. Khóa bí mật chỉ cần thiết để xác minh chữ ký hợp lệ (tức là token không bị giả mạo).

Dán JWT sản xuất ở đâ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, không có dữ liệu nào được gửi đến bất kỳ máy chủ nào. Token và khóa bí mật của bạn chỉ được xử lý trong môi trường JavaScript cục bộ và không bao giờ được ghi log hoặc truyền đi.

Sự khác biệt giữa HS256, RS256 và ES256 là gì?

HS256 sử dụng khóa bí mật HMAC chia sẻ (đối xứng). RS256 và ES256 sử dụng cặp khóa công khai/riêng tư (bất đối xứng), khóa riêng tư ký token và khóa công khai xác minh nó. Công cụ này hỗ trợ thuật toán HMAC; để xác minh RS256/ES256 hãy sử dụng thư viện phía máy chủ.