JWT 生成器
创建 JSON Web Token，自定义 Header 和 Payload
什么是 JWT？
JWT 生成器用于根据 Header、Payload 和签名设置创建 JSON Web Token。JWT 由三个 Base64URL 编码部分组成，常用于在服务之间传递用户 ID、角色、过期时间、签发方、受众等 claims。这个工具适合 API 测试、本地开发、教学、调试和快速生成示例令牌。但生成出的 token 是否可信，取决于密钥管理、算法选择、过期时间和服务端校验是否正确。不要把真实密钥粘到公开示例里，弱算法或过长有效期都有风险，敏感个人或业务数据也不应直接放进未加密的 Payload。
使用方法
JWT 生成流程
- 选择签名算法（默认 HS256）
- 输入或点击“生成”创建签名密钥
- 编辑 Payload JSON，使用快速添加按钮添加标准声明
- 设置签发时间（iat）和过期时间（exp）
- 点击“生成 JWT Token”按钮
- 复制生成的 Token 用于测试或开发
Token 安全
- HMAC 算法请使用强密钥，RSA/ECDSA 算法请妥善保管私钥。
- 请设置真实的 exp、iat、issuer 和 audience 声明；语法有效的 JWT 仍可能不安全或被服务拒绝。
使用场景
技术原理
JWT 生成与解析是逆向过程：解析负责拆开三段，生成则负责组装。核心是计算签名段。 组装流程：1) 构造 Header JSON，例如 {"alg":"HS256","typ":"JWT"}；2) 构造包含标准声明与自定义声明的 Payload JSON；3) 分别对 Header 与 Payload 做 Base64URL 编码，得到 h_b64 与 p_b64；4) 用「.」拼接 h_b64 与 p_b64，得到 input = h_b64 + '.' + p_b64；5) 按 alg 计算签名：HMAC-SHA256/384/512(secret, input)；6) 对签名结果再做 Base64URL 编码；7) 最终 token = input + '.' + sig_b64。 HMAC-SHA256 签名：用 secret 作为密钥（建议 ≥ 32 字节）对 input 做 HMAC。HMAC 内部跑两轮 SHA-256：先从 secret 派生 ipad/opad，再计算 SHA256(secret XOR ipad || msg) XOR opad。 密钥强度：secret 长度直接决定安全性。RFC 7518 要求 HS256 密钥 ≥ 256 位（32 字节）。生产环境务必使用密码学安全的随机源（例如 crypto.randomBytes），不要使用「secret」「password」「123456」之类的字符串。 常见坑：1) alg 替换攻击：服务端必须严格校验 alg，不能从 token 头中读取 alg 后再分派到对应算法；2) 弱密钥：过短的 secret 容易被爆破；3) Payload 篡改：HMAC 保证完整性，攻击者改动 payload 后服务端校验会失败；4) Token 泄露：JWT 不可撤销，一旦泄露只能等其过期。 本工具范围：仅生成 HS256/HS384/HS512。RS256（RSA）、ES256（ECDSA）等非对称算法需要发行方持有私钥，由后端签名服务或专用 SDK 完成，本页面不负责生成。
- HMAC-SHA256 签名核心：HMAC(secret, header_b64 + '.' + payload_b64)，输出 256 位签名并 Base64URL 编码。
- HS256 密钥长度必须 >= 32 字节（256 位）；建议使用 crypto.getRandomValues 或 crypto.randomBytes 生成——短密钥容易遭受字典攻击。
- 本工具仅生成 HMAC 系列签名（HS256/HS384/HS512）。RS256、ES256 等非对称算法需要发行方持有私钥，不在本工具生成范围内——如需此类 token，请使用后端签名服务或专用 SDK。
- iat/exp/nbf 都是 Unix 时间戳（秒，非毫秒）；服务端通常要求 exp > now()、nbf <= now() 且 iat <= now()。
- alg=none 攻击：维护服务端允许算法白名单（如 ['HS256']）；切勿从 token 头部动态选择算法。许多 JWT 库历史上默认允许 alg=none——这是已知漏洞。
- JWT 一旦签发无法撤销——唯一办法是等待 exp。如需主动撤销，维护 jti 黑名单或使用短期访问令牌加刷新令牌。
示例
基础 HS256 示例
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","name":"Alice","role":"admin","iat":1705312800,"exp":1705399200}
Secret: my-super-secret-key-32-bytes-long
Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNTMxMjgwMCwiZXhwIjoxNzA1Mzk5MjAwfQ.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4U通过 iat 与 exp 自定义有效期
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"iss":"https://auth.example.com","sub":"user-456","aud":"api.example.com","iat":1705312800,"exp":1705316400}
Secret: another-strong-secret-32-bytes-long
本工具会先对 Header 与 Payload 做 Base64URL 编码，用「.」连接，再用共享 secret 进行 HMAC-SHA256，最终输出三段式 Token，可直接粘贴到 Authorization 头。自定义声明
Header: {"alg":"HS256","typ":"JWT"}
Payload: {
"sub": "user-789",
"name": "Bob",
"role": "editor",
"tenant": "acme-corp",
"permissions": ["read:docs", "write:docs"],
"scope": "docs.read docs.write",
"iat": 1705312800,
"exp": 1705399200,
"jti": "550e8400-e29b-41d4-a716-446655440000"
}常见问题
JWT 是在本地生成的吗？
是的。头部、载荷和签名都通过浏览器 Web Crypto API 计算，签名用的密钥或私钥不会离开页面。但请注意，生成出的 token 本身可能被日志记录或暴露——尤其当你把它粘贴到真实服务里时。
支持哪些签名算法？
本工具生成 HS256/HS384/HS512（基于共享密钥的 HMAC）。RS256/RS384/RS512（RSA）和 ES256/ES384/ES512（ECDSA）等非对称算法本工具暂不生成，如需此类签名请使用后端签名服务或专用 SDK。生产环境请避免 alg=none：合规的校验方都会拒绝未签名 token。
载荷里应该放什么？
标准声明如 sub、iss、aud、exp、iat、nbf，再加上你的服务自定义的声明。载荷要保持精简——JWT 会附带在请求头中，每次请求都会膨胀。绝不要把密码、完整信用卡号或其他机密放进去；载荷只是 Base64URL，并未加密。
如何设置过期时间？
把 exp 设置为 token 应失效的 Unix 时间戳（单位是秒，不是毫秒）。不带 exp 的 token 在协议上合法，但生产环境基本都会强制要求。访问令牌通常 5-60 分钟，刷新令牌通常 7-30 天。
为什么我生成的 JWT 验证不通过？
常见原因：头部里的 alg 与验证方期望不一致；密钥/密钥对不同；载荷声明（iss、aud）不符合服务端配置；签发方与验证方时钟偏差超过容许范围（通常 ±60 秒）；手工编辑破坏了 Base64URL 编码（不要插入换行）。
我的密钥或私钥会发送到服务器吗？
不会。签名完全通过 Web Crypto 在浏览器内完成。但仍请注意：永远不要把生产环境的签名密钥粘贴到任何在线工具——先用非生产密钥测试，再到自己的后端做正式签名。
我应该用 HS256 还是 RS256？
HS256 需要双方共享同一密钥，仅适用于同一个服务既签发又验证 token 的场景。RS256（或 ES256）允许签发方持有私钥，所有消费者用公钥验证——这是 OAuth/OIDC 以及任何多服务架构的正确选择。 本工具仅生成 HS 系列 token；如需 RS256/ES256，请使用后端签名服务或专用 SDK。