Command Palette

Search for a command to run...

JWT 签名如何工作:HS256 vs HS384 vs HS512

JWT 签名如何工作:HS256 vs HS384 vs HS512

T
Toolz Team
|Sep 13, 2026|15 最小读数
Google 上的首选 Toolz.dev

安全集合的一部分

JWT 生成器

HS256、HS384 或 HS512 生成并签名 JSON Web 令牌,添加标准声明,并复制令牌。运行客户端。

用JWT 生成器

Laravel API上第一次要调试一个损坏的auth流,浪费了一个下午,因为我无法生成我信任的令牌,中间件一直返回401,我无法判断该错误是在我的验证码中还是在我正在馈送的令牌中,我需要一个具有特定功能的已知良好的JWT sub、特定的到期日,以及我控制的秘密,所以我可以隔离问题的一侧,从堆栈溢出答案中复制随机令牌与帮助相反,因为它是用我没有的秘密签名的。

JWT生成器填补的空白,那不是生产签名服务,它是你正在构建或测试消耗JSON Web Tokens的东西的那一刻的台式工具,你需要一个有效的按需,有确切的声明和你选择的确切秘密,本指南涵盖了工具的工作原理,JWT是如何组装和签名的,以及用手生成令牌的实际案例,可以节省你的实时。

TL;博士: JWT生成器将JSON有效负载加上一个秘密变成一个签名令牌,粘贴你的声明,选择HS256,HS384或HS512,输入秘密,并复制令牌。的 JWT 生成器 web Crypto API 的浏览器进行签名,因此有效负载和秘密永远不会离开您的机器。使用它创建具有已知功能的测试令牌 sub的、集合过期,或者故意过期 exp 要锻炼您的 API's 错误路径。要读取令牌返回,请将其与 jwt解码器。

什么是 JWT 以及生成器会产生什么?

JSON Web 令牌是一种紧凑的、URL 安全的表示一组权利要求的方式, 结构由 RFC 7519 定义, 签名形式, 这几乎是每个人通过 "a JWT, " 所表示的, 是由 RFC 7515 定义的 JSON Web 签名令牌, 它有三个部分由点连接: header.payload.signature。

标头是一个小型 JSON 对象,命名签名算法和令牌类型,类似 { "alg": "HS256", "typ": "JWT" }。有效负载是权利要求的JSON对象:令牌是关于谁的,到期时,以及您的应用程序添加的任何自定义字段。标头和有效负载都是Base64url编码的,这是普通的base64,有两个字符替换,没有填充,完全按照RFC 7515的规定。签名是在前两部分上计算的键控哈希。

生成器将这三个都组装起来。您提供有效负载和秘密,它构建标头,对两个段进行编码,计算签名并连接它们。输出是一个字符串,您可以直接将其放入一个字符串中 Authorization: Bearer 头、测试夹具或 curl 命令。

1件值得在前面直言不讳的事情:一个签名的JWT是编码的,而不是加密的,任何持有令牌的人都可以Base64url-解码有效负载并读取其中的每一个声明,签名不会隐藏内容,它只是证明内容不是由没有密钥的人更改的,永远不要把密码,API密钥,或者其他任何你不会在JWT有效负载内向用户展示的东西。

签名如何运作?

HMAC家族来说,也就是这个工具所签名的,签名就是 HMAC(secret, header + "." + payload)。HMAC是由RFC 2104定义的键控哈希结构,JWA规范RFC 7518将三个JWT算法名称映射到其上:HS256使用HMAC与SHA-256,HS384使用SHA-384,HS512使用SHA-512。

重要属性是对称性,同一个秘密既创建签名又验证签名,当你的服务器收到令牌时,它会重新计算 HMAC(secret, header + "." + payload) over 接收到的前两个段,并检查结果等于签名段,如果改变有效负载的单个字节,重新计算的哈希将不匹配,验证失败,那就是整个完整性保证。

为对称,秘密就是整个游戏,任何拥有秘密的人都可以为你的系统铸造有效的令牌,这就是为什么生成器通过Web Crypto API在你的浏览器中运行签名,并且从不在任何地方传输秘密,你可以通过打开你的浏览器来确认这一点's网络选项卡,同时你生成一个令牌:没有请求。这比听起来更重要,因为将一个实时制作签名秘密粘贴到一个随机的Web工具中,手机回家将把钥匙交给你的身份验证。

RS256和ES256,非对称算法,工作方式不同:私钥符号和匹配的公钥验证,当许多服务需要验证令牌但只有一个应该能够发出这些令牌时,这些都是正确的选择,这个工具故意不提供它们,因为与它们签名意味着将私钥粘贴到网页中,这是一个永远不值得开始的习惯。

JWT生成器的使用方法

1步:写出有效载荷

JSON 对象输入您的声明,一个最小的例子是 { "sub": "1234567890", "role": "admin" }. X = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 = 1000 sub claim为主题,通常是用户id,你可以添加你的应用程序读取的任何自定义字段,例如 role、 scope、 tenant_id、或者 email。工具将您放在这里的任何内容完全按照书面形式保留。

步骤 2:添加时间声明

留下已发行和工具印章 iat unix当前时间。设置一个以秒为单位的过期,以添加一个 exp 声明按现在计算加上该偏移量。对于十五分钟的访问令牌,输入 900。对于一小时的令牌,输入 3600。这些是大多数身份验证错误归结为的声明,因此正确计算它们,从纪元开始,以秒为单位,而不是毫秒,消除了常见的错误。

3步:选择算法和秘密

HS256 选取,除非你有理由使用 HS384 或 HS512 在字段中输入签名秘密,然后选择秘密的解释方式:纯文本使用你键入的 UTF-8 字节,而 base64url 和 hex 首先将字符串解码为原始字节,这个选择很重要,因为许多系统存储已经 base64 编码的秘密,如果你将编码的字符串作为纯文本馈送,你会产生一个不匹配的签名。

4步:复制令牌

JWT 签名,同时显示头部和有效负载的解码预览,因此您可以在使用前确认每个声明。将其复制并粘贴到任何需要的地方。

为什么要手工生成代币?

API 测试 's 幸福之路

当您编写验证 JWT 的中间件时,您需要代码应接受的令牌。生成一个与验证者使用的相同秘密签名的,并具有有效的 exp并且确认请求返回200,如果没有,bug在你的验证逻辑中,而不是token,这个单次隔离步骤就是我最常到达工具的原因。

测试故障路径

强大的 API 出于正确的原因拒绝了权利令牌。生成带有 a 的令牌 exp 已经过去了,确认您返回正确的过期令牌错误。生成一个带有 a 的 nbf 未来测试尚未有效的路径。生成一个带有错误秘密的签名以确认您的签名检查运行。这些阴性情况是未经测试发货的情况,生成器使它们成为三十秒的工作。

从特定用户复制错误

Support 报告一个问题,只发生在具有特定角色的帐户。生成一个具有该精确度的令牌 role 索赔和受影响的用户's sub(bear),并且您可以在本地复制请求,而无需触摸生产数据或向用户索要其真实的承载令牌,无论如何,您都不应这样做。

播种当地发展

团队中的新开发人员需要一个工作令牌才能在前端 auth 仍在构建时命中受保护的端点。与本地开发秘密签名的生成令牌会立即解锁它们。

HS256 vs HS384 vs HS512:您应该使用哪些?

算法 哈希 签名尺寸 最小密钥长度 何时使用
HS256 SHA-256 32个字节 32个字节 默认。快速、广泛支持、几乎所有用途都安全
HS384 SHA-384 48个字节 48个字节 当政策或标准需要 SHA-384 时
HS512 SHA-512 64个字节 64个字节 高安全性环境,或者当您已经在 SHA-512 上标准化时

HS256的实用答案,除非外部需要其他东西。RFC 7518要求密钥至少与哈希输出一样长,因此HS256为32字节,HS384为48,HS512为64。当你的解码秘密比最小值短时,生成器会发出警告,因为无论算法名称如何,短密钥都会削弱签名。更长、编号更高的算法不会修复弱秘密;适当长度的随机秘密才是最重要的。

常见错误以及如何避免它们

最常见的是编码引起的秘密不匹配,您的框架将秘密存储为 base64,将 base64 字符串粘贴为纯文本,现在密钥字节与验证者使用的不同,签名永远不匹配,您会追逐幻象错误。通过在工具中选择正确的秘密编码来修复它,因此原始密钥字节两侧相同。

2是令人困惑的秒和毫秒,RFC 7519中注册的时间声明都是以Unix时代以来的秒为单位测量的,JavaScript's Date.now() 返回毫秒。如果你计算的话 exp 1000除以你自己,忘记了,你的令牌似乎从现在起五万年后失效,一些严格的验证者会拒绝,让生成器计算声明完全避免了这一点。

3是把有效载荷当成私密的,不是,如果诱惑在索赔中存储秘密,就停止,任何拥有令牌的人都可以阅读,只存储你对令牌持有者看到的感到舒服的东西,并在服务器上保留真正的秘密数据。

JWT 与其他工具并存的地方

一旦生成了令牌,自然的下一步就是读回它。 jwt解码器 将任何令牌分割成其标头和有效负载并标记已过期 exp,就是你确认生成器产生你想要的,如果你也在产生秘密,the 哈希生成器 计算 SHA 哈希客户端,并且 密码生成器 产生一种长随机字符串,它首先会使 HMAC 秘密变得很好。如果您想手把手地了解 Base64url, Base64 编码器/解码器 显示相同的可逆变换,将标头和有效负载转换为其编码形式。当您需要随机标识符时,请将其放入 a 中 sub 或 jti 声称, UUID 以正确的格式为您提供一个。

为了更广泛地了解为什么基于浏览器的工具会将敏感材料从第三方服务器上删除, 在线工具中的数据隐私 指南解释了客户端模型,以及 web开发人员工具包 将与令牌工作配对良好的实用程序进行舍入。

服务器如何验证您生成的令牌?

知另一边会发生什么,这很有帮助,因为它解释了为什么秘密和主张必须完全正确,当你的 API 收到令牌时,像 jsonwebtoken、jose 或 PyJWT 这样的库会按顺序将令牌分割在点上,Base64url-解码头读取 alg。它重新计算签名 header.payload 使用配置的秘密并将其逐字节与签名段进行比较。它检查已注册的声明:是 exp 过去,是 nbf 未来,确实如此 iss 並 aud API 的期望相匹配。

这些检查中的每一个都映射到生成器允许您控制的东西。如果签名验证失败,则两侧的秘密或其编码会有所不同。如果它失败了 exp的,令牌已经过期,你可能故意造成测试那条路径,如果它失败了 alg(inception) 验证者未配置接受的算法生成令牌,这本身就是一个有用的发现。生成带有故意变体的令牌是如何准确地映射出哪些检查你的 API 强制执行,哪些它默默跳过。

一个字 alg header 具体来说。 RFC 7515 定义 none 作为未签名令牌的有效算法,早期的库会信任声称的令牌 alg: none 并完全跳过验证。那是经典的 JWT 漏洞。现代库默认拒绝它,但生成器提供 none option 精确地,这样你就可以向你的 API 发射一个未签名的令牌,并确认它说不。如果你的 API 曾经接受过一个,你已经发现了一个严重的错误。

您应该如何处理秘密和代币存储?

您签名的秘密值得与数据库密码一样小心。一个好的 HMAC 秘密是一个长而随机的字符串,而不是一个令人难忘的短语,因为 HMAC 安全性取决于密钥无法猜测。使用密码工具生成一个并将其存储在您的环境配置中,永远不会在源控制中,这是基线。当您旋转它时,请记住,每个用旧秘密签名的令牌在验证器切换的那一刻就失效,这就是为什么生产系统通常在旋转窗口期间支持多个有效秘密。

在客户端,您存储完成的令牌的位置与您如何签名一样重要。一个令牌 localStorage javascript在页面上的任何一个都可以读取,因此单个跨站脚本缺陷会给攻击者带来一个有效的凭据。an httpOnly、 Secure、 SameSite cookie对脚本是不可见的,脚本以需要csrf保护为代价关闭了那个路径,常见的模式是保存在内存中的短命访问令牌和更长寿的刷新令牌 httpOnly cookie。这些都没有改变你生成令牌的方式,但正是上下文使生成的令牌可以安全使用,而不是责任。

常问问题

如何生成 JWT?

JSON 对象粘贴你的声明,挑选 HS256 等签名算法,进入秘密 工具 base64url- 对标头和有效负载进行编码,计算 HMAC 签名,返回完成令牌,让您复制所有内容在浏览器中运行。

支持哪些签名算法?

HS256、HS384、HS512,HMAC家族,加上一个未签名的"无"选项进行测试,RS256和ES256故意不提供,因为它们用私钥签名,并且将私钥粘贴到网页中是最好避免的安全风险。

我的秘密被发送到服务器了吗?

号签名通过Web Crypto API完全在你的浏览器中运行,所以秘密和有效负载永远不会离开你的设备,你可以在DevTools Network选项卡中确认这一点,一旦加载,该工具就会保持离线工作。

如何将令牌设置为过期?

在几秒钟内输入过期,工具会添加一个 exp 声明等于当前时间加上那么多秒 对于一个十五分钟的令牌输入 900 空格以省略 exp 完全。

为什么秘密至少应该是 32 字节?

RFC 7518需要HMAC密钥至少与哈希输出一样长,HS256为32字节,HS384为48,HS512为64。较短的秘密会削弱签名,因此当解码的秘密太短时,工具会发出警告。

我可以创建一个未签名的令牌吗?

是选择 alg none,工具会产生一个头。payload。token,带有空签名。这仅用于测试您的 API 如何处理未签名的令牌;大多数库默认拒绝 alg:none,您也应该拒绝。

生成的 JWT 是否加密?

No。A 签名的 JWT 是编码的,而不是加密的:任何人都可以 base64url-解码头和有效载荷并读取每个声明,签名只证明内容没有改变,切勿将密码或秘密放入有效载荷内部。


Comments

0 comments

0/2000 characters

No comments yet. Be the first to share your thoughts!