跳到正文

JWKS 签名验证

JWKS Verifier

拉取 JWKS 端点,按 kid 选出对应的密钥,验证令牌的签名和标准声明。

用签发方公布的 JWKS 验证一个令牌——按 URL 抓取或粘贴——按 `kid` 选出密钥,检查签名,然后检查 `exp`、`nbf`,以及你指定了的话 `iss` 和 `aud`。令牌从不发送;抓取的只有 JWKS URL。

🔒 完全在你的浏览器里运行jwtjwksauthverify

令牌不会离开这个标签页。

签名校验由浏览器的 WebCrypto 完成,这个页面没有服务端。唯一的网络请求,是对你输入的 JWKS URL 发一次 GET,而那次请求除了 URL 什么都不带——也不带令牌。

令牌

Bearer 前缀会自动去掉。

公钥(JWKS)

密钥来源

浏览器直接 GET 它。不会发送令牌。

签发者的 /.well-known/openid-configuration 里的 `jwks_uri` 就是这个地址。

期望值(可选)

允许的时钟偏差

留空就不检查那个声明。exp 和 nbf 总是检查。

检查了什么

  • · RS256/384/512、PS256/384/512、ES256/384/512 和 EdDSA(Ed25519)用 WebCrypto 校验(RFC 7518 §3、RFC 8037)。HS* 用共享密钥,根本没法拿 JWKS 来校验——那些交给 JWT 解码器用密钥去查。ES256K 和 Ed448 在任何浏览器的 WebCrypto 里都没有。
  • · 密钥是按令牌头部里的 kid选的(RFC 7515 §4.1.4)。轮换密钥的时候 JWKS 里会同时放着几把,所以 kid 对不上就会明说。
  • · exp、nbf按偏差容差来检查; iss、aud只在你填了期望值时才检查(RFC 7519 §4.1)。 alg: none一律拒绝。

怎么用

  1. 粘贴令牌

    它的 `alg`、`kid` 和签发方会立刻读出来,这告诉你需要哪一份 JWKS。

  2. 抓取或粘贴密钥集

    签发方的 `/.well-known/openid-configuration` 里写着它的 `jwks_uri`。Google、Microsoft 和 Apple 有快捷按钮;其他的你输入或粘贴。

  3. 填上你的预期

    你留空的 `iss` 和 `aud` 根本不会检查——真实系统里给另一个受众的令牌就是这样被接受的。时钟偏差容忍覆盖相差一分钟的服务器。

  4. 读结论和声明表

    横幅说接受或不接受;下面的表说是哪一项检查给出了这个答案、选中了哪把密钥。

常见问题

抓取失败,报了 CORS 错误。

浏览器要能读 JWKS 端点,端点必须发送 CORS 头。Google、Microsoft 和 Apple 会发;不少自托管的签发方不发。自己用 curl 抓下来把 JSON 粘进来——两种方式下验证是完全一样的。

它说没有密钥匹配这个 kid。

通常是密钥轮换:令牌在签发方轮换之前签的,JWKS 现在只有更新的密钥。也可能意味着令牌来自另一个签发方,而不是你抓的这份 JWKS 的。

为什么 `alg: none` 总是被拒绝?

因为接受它就是那个经典的 JWT 漏洞:攻击者改写头部、去掉签名,一个信任头部的库就放行了令牌。在验证路径上它没有任何正当用途。

它能检查 HS256 令牌吗?

这里不能——HS* 是共享密钥,而 JWKS 公布的是公钥。用 JWT 解码工具,它接受密钥。一个在 JWKS 里公布 HMAC 密钥的签发方,公布的是铸造令牌的能力。

可以从这些接进来

接下来

这些工具吃得下当前工具的产出,结果可以直接送过去。