在线JWT编码器: 无需安装即可创建并签署令牌

每个开发者大致在同一个时刻学习什么是JWT: 第一次需要实现认证而有人建议使用它的时候。你阅读RFC，查看base64解码后的负载，心想「哦，这就是JSON而已」——然后接下来的一个小时都在困惑签名部分到底在做什么以及为什么。

这种困惑可以理解。JWT结构简单但在安全含义上很微妙。本指南聚焦实用方面: 你实际上需要知道什么才能创建和使用JWT进行测试和调试，以及ToolBox Hubs的JWT编码器如何让你做到这一点而无需安装库或启动服务器。

JWT到底是什么

JSON Web Token是用点连接的三个base64url编码的字符串: header.payload.signature。

头部 标识令牌类型和签名算法:

{
  "alg": "HS256",
  "typ": "JWT"
}

负载 包含声明——基本上是信息的键值对:

{
  "sub": "user_12345",
  "email": "alice@example.com",
  "role": "admin",
  "iat": 1714000000,
  "exp": 1714086400
}

签名 是使用你的密钥创建的编码后头部和负载的加密哈希。这就是让令牌防篡改的东西——改变负载中的一个字符，签名就不再匹配。

这里有个让很多人困惑的事情: 负载没有加密。它是base64url编码的，意味着任何持有令牌的人都可以立即解码并阅读它。签名证明令牌没有被篡改，但完全不会隐藏内容。这对你决定放什么进去非常重要。

你实际使用的声明

JWT规范定义了少量「注册声明」——具有标准含义的字段名，库知道如何自动验证。

sub (主题) — 令牌是关于谁的。通常是用户ID或账户标识符。应该稳定且唯一。一个常见错误: 在这里放电子邮件地址而不是不透明的ID。电子邮件地址会变，不透明的ID不会。

iat (签发时间) — 令牌创建时的Unix时间戳。对调试有用，一些验证逻辑会检查这个以拒绝看起来来自远未来的令牌 (时钟偏差攻击)。

exp (过期时间) — 令牌应被拒绝的Unix时间戳。这很重要。没有过期时间的JWT永久有效，意味着如果它泄露，除了完全轮换密钥外你别无选择。对于短期会话，15-60分钟很常见。对于刷新令牌，几小时到几天。始终设置这个。

iss (签发者) — 标识谁签发了令牌的字符串。在多服务环境中很有用，可以确保你正在验证来自正确来源的令牌。你的验证中间件可以检查 iss 是否匹配预期值并拒绝其他任何东西。

aud (受众) — 令牌的预期接收者。防止为服务A签发的令牌被用于服务B。通常是API标识符或应该接受令牌的服务列表。

自定义声明是可以的且常见。如果你的应用需要嵌入 role、plan、org_id 或任何其他上下文到令牌中以避免每次请求的数据库查找，也添加它们。只是要记住: 任何人都能阅读它们。

你什么时候真的会用在线JWT编码器

诚实的答案是: 不用于生产。对于生产，你的认证服务器处理签名——你的密钥永远不离开服务器环境，令牌作为登录流程的一部分以编程方式生成。

在线编码器真正有用的地方:

在没有运行的认证服务器的情况下测试认证中间件。 你正在构建验证JWT的后端端点，想要手动测试它。你需要一个用已知密钥签名的有效令牌粘贴到Postman或curl中。在线编码器在几秒钟内就能给你。

在本地开发中模拟认证。 你的前端正在针对需要认证的API构建，但认证服务尚未在本地设置。生成一个具有正确声明和测试密钥的令牌，硬编码到你的开发环境中，继续前进。你不是在发布这个; 你是在解除本地开发的阻塞。

调试令牌验证失败。 一个令牌被你的服务器拒绝，你不确定为什么。exp 在过去? iss 错了?负载格式错误?编码器让你创建一个已知良好的令牌进行比较，JWT解码器让你检查那个坏的。一起使用它们就形成一个调试循环。

第一次理解JWT行为。 理解库对JWT做什么的最好方法是自己创建一个并观察发生了什么。调整过期时间，改变算法，观察什么会失败。在线工具让这变得动手实践，没有代码的摩擦。

HS256签名如何工作 (没有数学)

HS256代表HMAC-SHA256。HMAC是一种结构，它使用哈希函数 (本例中为SHA-256) 与密钥一起生成消息认证码。

用通俗的话讲过程: 取编码后的头部，加一个点，加上编码后的负载。把这个字符串和你的密钥输入到HMAC-SHA256函数中。你得到一个固定长度的哈希。把那个哈希进行base64url编码，并作为令牌的第三部分附加。

为什么这有效?因为HMAC的设计使得在不知道密钥的情况下，你无法为给定的消息生成有效的哈希。如果有人修改了负载，他们无法重新计算签名以匹配——他们需要密钥才能做到。当你的服务器验证JWT时，它会对收到的头部和负载重新运行相同的HMAC-SHA256计算，将结果与令牌中的签名进行比较，并相应地接受或拒绝。

ToolBox Hubs编码器使用浏览器内置的Web Crypto API进行此计算——浏览器用于TLS的相同加密原语。它不是用手写的JavaScript或可疑的第三方库做的。这一点值得知道。

HS256做不到什么

HS256使用对称密钥——签名令牌的密钥也用于验证。这意味着任何能验证你的令牌的人也能创建它们。在一个服务器签发令牌而另一个验证的系统中，两台服务器都需要知道密钥。在服务之间共享密钥是协调和安全表面的问题。

RS256 (和ES256) 使用非对称密钥。私钥签名令牌——只有认证服务器需要它，并且它永远不离开那台服务器。公钥验证令牌——这可以自由分发，发布在JWKS端点中，由任何需要验证令牌的服务加载。服务可以验证而没有任何铸造能力。

对于比单个后端服务更复杂的任何东西，RS256通常是更好的架构选择。HS256更容易设置，对于较小的系统或你控制所有验证器的场景来说很好。

值得重复的安全事项

不要把敏感数据放在JWT里。 密码哈希、信用卡号、不必要的PII——一概不要。负载对持有令牌的任何人都可见。这包括客户端、捕获认证头的任何日志系统，以及中间的任何代理或CDN。把JWT负载当作URL查询字符串来对待: 假设它是可见的。

对在线工具使用测试密钥。 即使工具确实是客户端的并且不向任何地方发送你的数据，把生产密钥输入到浏览器UI中的习惯也是不好的。创建一个测试密钥。如果你愿意，用 test-secret-do-not-use-in-production 作为你的密钥。把真正的密钥当作密码: 它不会离开它所在的服务器。

始终设置过期时间。 没有 exp 的JWT是一个永久凭证。如果它泄露，你将有问题，直到你轮换签名密钥——这会使所有现有令牌失效并让所有人退出登录。短期令牌加上刷新令牌流程是标准模式是有原因的。

算法混淆攻击是真实的。 一些JWT库历史上有漏洞，你可以将 alg 头部更改为 none，库会接受未签名的令牌。始终验证你的服务器期望的算法并拒绝其他任何东西。不要信任来自令牌本身的 alg 头部。

ToolBox Hubs vs. jwt.io

jwt.io是规范的JWT工具，大多数开发者都知道它。它很好。但有两个原因你可能更喜欢ToolBox Hubs:

首先，ToolBox Hubs明确以隐私为先且仅限客户端。jwt.io历来受到关于输入到其中的密钥是否可能被记录的审视。我不是说jwt.io有恶意——但当一个工具的隐私模型没有清楚记录时，风险计算会改变。我们的工具在你的浏览器中处理一切。

其次，ToolBox Hubs与相关工具集成。编码JWT后，你可以直接跳转到JWT解码器检查它，如果需要哈希任何值，可以通过哈希生成器运行负载，或者如果需要对JWT负载不应该以明文携带的内容进行对称加密，使用文本加密/解密。

话虽如此: jwt.io有我们没有的功能，包括库选择和带有密钥对生成的RS256支持。请使用适合你需求的正确工具。

本地开发的实用工作流程

这是我在开发期间实际使用JWT编码器的方式:

1. 决定令牌需要什么声明——通常是 sub、exp，以及你的中间件检查的任何应用特定声明 (如 role 或 org_id)。

2. 将 exp 设置为足够远的未来，使其在调试会话期间不会过期。我通常使用当前Unix时间加上86400 (24小时)。时间戳转换器有助于心算。

3. 输入一个易记的测试密钥——明显是假的东西，比如 dev-secret-not-real。

4. 生成令牌并粘贴到你的API客户端 (Postman、curl、HTTPie，任何东西)。

5. 当验证出现问题时，将令牌粘贴到JWT解码器中确认负载看起来正确，然后检查你的服务器期望的密钥和算法是否与你用于生成它的匹配。

这个循环解决了90%的JWT相关调试困惑。剩下的10%通常是时钟偏差 (你的 exp 偏离) 或算法不匹配 (你生成了HS256，你的库期望RS256)。

工具不会做什么

诚实地谈论局限性:

没有RS256或ES256支持。 不可用非对称密钥签名——你需要提供私钥，在浏览器UI中处理它会增加复杂性。对于RS256测试，本地的 jsonwebtoken npm包或 python-jose 库更合适。

没有令牌撤销。 JWT在设计上是无状态的——一旦签发，它们在过期前都有效 (假设签名验证通过)。没有内置的撤销。如果你需要在令牌过期之前使其失效的能力，你的服务器需要一个令牌阻止列表。编码器在这方面帮不上忙; 这是架构问题。

没有JWKS生成。 对于基于RS256的系统，你还需要一个JWKS (JSON Web Key Set) 端点。这超出了此工具的范围。

对于范围内的一切——创建用于测试和调试的HS256签名令牌、理解JWT结构、在本地开发中模拟认证——JWT编码器无需仪式即可完成工作。

入门

打开JWT编码器工具，输入一个简单的负载，如 {"sub": "test-user", "role": "admin"}，设置一个测试密钥，然后点击Generate。看看输出。然后将其粘贴到JWT解码器中，看着它分解。

一旦你做过一次，JWT结构就不再抽象。你知道三个部分是什么，你知道base64url编码的JSON是什么样子，你知道签名只是一个哈希。其他一切——库集成、算法选择、声明验证——都建立在那个基础之上。

值得与此工具一起打开的相关工具: 用于检查令牌的JWT解码器，用于理解HMAC生成什么的哈希生成器，以及用于base64编码明文确实不够好的情况的文本加密/解密。