JWT 签名与验证

你的密钥永不离开本页

签名与验证使用浏览器自带的 WebCrypto，操作的是你粘贴或在这里生成的密钥。密钥与私钥只存在于页面内存中：不上传、不写入 localStorage 或 cookie，也不放进 URL。刷新或关闭页面，它们就消失了。唯一的例外是 JWKS URL 获取，由你自己发起：它只发送你输入的 URL，去取回公开密钥——绝不发送密钥。把生产密钥粘贴到任何地方之前，先读一读签名与验证 JWT。

如实说明的局限

EdDSA 需要较新的浏览器：老浏览器没有 WebCrypto Ed25519，本页会如实说明，而不是伪造签名。ECDSA P-256 是处处可用的后备方案。

加密 PEM（用口令锁住的私钥）第一版不支持。本页会公开拒绝——请先用 openssl pkcs8 -topk8 -nocrypt 解密，并且永远不要把口令粘贴进网页。

JWKS URL 获取依赖对方服务器发送 CORS 响应头。多数身份提供方会发送；不发送的，获取会如实失败，本页会提示你改为粘贴 JWKS。获取的永远只有公开密钥——JWKS URL 里绝不会有密钥。

什么时候签名胜过解码

解码 JWT 就是读它：头部和载荷是 base64url，拿到令牌的任何人都能看到这两段。正因如此，只靠解码器永远回答不了唯一真正重要的问题——签发方真的签过它吗？签名是这项工作的另一半：持有私钥（或 HMAC 密钥）的一方生成签名，验证方用公钥重算同样的数学。本页把这两半都留在你的浏览器里，因为涉及的密钥是任何网页工具处理过的最敏感输入。

这种区分在非对称算法上最重要。用 HS256，验证用的密钥就是签发用的密钥——能校验你令牌的人也能铸造令牌，在一个服务内部这没问题，出了这个范围就是泄露。用 RS256、ES256 或 EdDSA，签发密钥留在签发方手里，只有公钥会传播：你的 API 可以发布自己的 JWKS，新增一个 kid 来轮换密钥，让全世界的验证方都能校验令牌，而没有任何一方握有伪造令牌的能力。

本工具拒绝做的事

有两项拒绝是刻意的。第一是 alg: none：声称不需要签名的令牌会被直接拒绝，并给出原因——接受它的验证方就是在接受伪造品。第二是算法混淆：用 HMAC 密钥递上 RS256 令牌（或反过来）会带着明确警告失败，绝不会悄悄把密钥按另一族重新解释。这两种都是经典的 JWT 攻击，而这里的防护是结构性的——密钥所属的族必须与令牌的 alg 所属的族匹配，否则验证失败。

第三项拒绝更微妙：本页永远不会告诉你一个令牌是“可信的”。有效的签名只证明令牌由持有密钥的一方签发、且在有效期内——仅此而已。是否信任这把密钥，取决于它从哪里来：从身份提供方的 well-known URL 获取的 JWKS、你自己钉住的公钥、你生成的密钥。指南签名与验证 JWT会一步步讲清“已验证”能证明什么、不能证明什么。

JWT 术语，一一说清

JWT. JSON Web Token（RFC 7519）：在各方之间传递声明的紧凑、URL 安全的方式——头部.载荷.签名，每段都是 base64url 编码。载荷任何人都能读；只有签名依赖密钥。

JWS. JSON Web Signature（RFC 7515）：JWT 之下的签名格式。JWT 就是载荷为 JSON 声明集的 JWS。

JWK. JSON Web Key（RFC 7517）：表示一把密码学密钥的 JSON 对象——kty，以及密钥材料（RSA 的 n/e、EC 的 x/y、Ed25519 的 x、共享密钥的 k）。

JWKS. JSON Web Key Set：带 "keys" 数组的对象——签发方发布公钥的标准方式，通常位于 /.well-known/jwks.json。

kid. 密钥 ID：说明哪把密钥签了这个令牌的头部声明。验证方拿它与 JWKS 比对；没有它时，若密钥集只有一把密钥就用那一把，本页会如实说明。

alg. 命名签名算法的头部声明（HS256、RS256、ES256、EdDSA……）。验证方必须钉住自己接受的算法——信任令牌自己的 alg 声明，就是混淆攻击。

HMAC. 基于哈希的消息认证码：对称签名——同一把密钥既签名又验证。快速简单；持有密钥的每个人都能铸造令牌。

RSASSA-PKCS1-v1_5. RS256/384/512 背后的 RSA 签名方案：对哈希做包装，再以私钥指数运算。确定性的——同一输入永远得到相同的签名字节。

EdDSA. Edwards 曲线数字签名算法：这里指 Ed25519——密钥小、验证快、签名确定性。WebCrypto 支持需要较新的浏览器。

常见问题