🪪 JWT 生成 & 签名
输入 header、payload 和 secret,完全在浏览器中生成已签名的 JWT。支持 HS256 / HS384 / HS512(Web Crypto API)。
⚠️ 安全提示
• 密钥仅在浏览器中通过 Web Crypto API 处理,绝不发送到服务器。
• 不建议在 Web 工具中输入生产环境的密钥。请用于测试、学习和调试。
• HS256 密钥应至少 256 位(32 字节);HS512 应至少 512 位(64 字节)。
🔗 相关工具
📖 常见的坑
输入头部、载荷与密钥，即可用 Web Crypto API 在浏览器内生成已签名的 JWT（HS256 / HS384 / HS512）。iat 与 exp 可通过按钮添加。密钥不会被发送到服务器。不过关于 JWT，有一件事需要最先弄清楚——JWT 不是加密。载荷只是做了 Base64URL「编码」，任何人不需要任何密钥就能读出内容。签名保证的只是「没有被篡改」，对「没有被看到」不作任何保证。
| 情形 | 会发生什么 | 怎么处理 |
|---|---|---|
| 把生产环境的密钥输入到浏览器工具里 | 本页不会把值发往服务器，但「不传输」与「不留痕迹」是两回事。你输入的字符串存在于 DOM 中，可能留在浏览器的输入历史与自动填充里，会出现在截图与屏幕共享中，而且你安装的任何扩展都能读取页面内容。一旦复制，它还会进入剪贴板历史工具。最常被忽略的是生成出来的令牌本身：为了调试而贴到 Slack 或工单里的 JWT，即便密钥从未泄露，在它有效期内仍然可用——JWT 是 Bearer 令牌，持有者即被当作本人。 | 本页请只输入一次性的密钥。用「随机生成」按钮造出来的值就够了——如果目的只是确认签名机制，它不必是真的。如果你已经贴了生产环境的密钥，补救办法只有一个：立刻轮换。抱着「大概没事」放着不管，日后就再也没有办法判定它是否泄露过——而且HMAC 的密钥只要抓到一个令牌就能在本地穷举，因此字典里的词和短字符串尤其危险。更好的做法是，从设计上就让生产密钥不经人眼——让它直接从环境变量或密钥管理服务读取，压根不制造复制粘贴的通路，这最为有效。 |
exp 只在验证方那一侧起作用 |
exp 只是一个字段，并不是「时间一到令牌就自动失效」的机制——只有验证方读取该值并予以拒绝，它才作为有效期起作用。由此衍生出四个经典缺陷。(1) 忘记加 exp，这个令牌就永久有效。(2) 单位搞错——JWT 中的时间是「自纪元起的秒数」，而 JavaScript 的 Date.now() 返回毫秒，直接塞进去会指向五万年之后。(3) 服务器之间的时钟偏差会让刚签发的令牌卡在 nbf 上被拒绝。(4) 已签发的令牌无法撤销——退出登录也好，改密码也好，它都会一直有效到 exp。 |
访问令牌的 exp 请设得短一些——15 分钟到 1 小时是常见的经验值。长期登录状态改用刷新令牌来维持，并把它存在服务端，以便单独作废。要正面解决「无法撤销」这个问题，只有这条路。若「立即失效」是硬性需求，就加上 jti（令牌 ID）并维护一份拒绝名单——但到那一步，你已经放弃了当初选用 JWT 的「服务端无状态」这一优势，所以请先确认这项需求是否真实存在。在验证方的实现中，比较 exp 与 nbf 时请留出数十秒的容差（leeway）。另外，时间单位一律用秒——JavaScript 中为 Math.floor(Date.now() / 1000)。 |
验证方相信了令牌里的 alg |
头部里的 alg 位于攻击者可以改写的地方——读取它来决定验证方式的库，等于把验证方式的选择权交给了攻击者。有两种著名的攻破方式。(1) alg: none——写入表示「无签名」的值并把签名段留空，实现天真的库就会照单全收。(2) RS256 与 HS256 混淆——把本应用 RSA 公钥验证的令牌，把 alg 改写为 HS256，并用那把公钥当作 HMAC 密钥来签名。公钥本来就是公开的，攻击者因此可以随意伪造出有效令牌。两者都是实现层面的 bug，而不是 JWT 本身的缺陷。 |
在验证方，请把要使用的算法作为固定值传入。大多数库都接受形如 algorithms: ['HS256'] 的参数——即便 API 允许省略，也不要省略。从令牌中读到的 alg 不是验证的输入，而是被验证的对象之一。密钥同样要固定，若需轮换多把密钥，请通过 kid 选取，并且务必只在自己的密钥集合中选。也别忘了密钥强度：HS256 请使用至少 256 位（32 字节）的随机值，绝不要用能记住的口令——HMAC 只要有一个令牌就能离线随意验证，字典攻击因而成为现实威胁。最后一点：不要自己造这个库。 |
不要把机密放进载荷。再说一遍：任何人都能读到它——把邮箱、电话号码、权限明细、内部 ID 放进去，就等于向所有看到该令牌的人公开了它们。设计时请记住，任何人打开浏览器的开发者工具都能读出自己令牌的内容。请把声明保持在最小限度，细节等真正需要时再向服务器索取。而且很多场景下 JWT 本来就不是最优解——同一域名下的普通 Web 应用，用服务端会话更简单，而且可以立即登出。JWT 真正发挥价值的地方，是跨多个服务的认证，或者验证方无法回头询问签发方的架构。「因为它现代」不构成理由——请以「你能否接受这个取舍：以无法撤销为代价换取无状态」来做选择。
📖 使用方法
-
1
设置算法和 payload选择算法并输入 Payload JSON Claims。
-
2
输入或生成密钥输入密钥或点击随机生成按钮。
-
3
复制生成的 JWT签名后的 JWT 立即显示在右侧面板。
❓ 常见问题
HS256、HS384、HS512 的区别?
在此输入生产密钥安全吗?
是否支持 RS256 或 ES256?
🐛 此工具出现问题了吗？
免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。
感谢您的反馈！
已送达运营者,将用于改进工具。