摘要

  • 2026 年 8 月 24 日，IESG 批准 draft-ietf-oauth-rfc8725bis-10 以最佳当前实践发布。证据冻结时，它仍是处于 RFC Editor 队列的 Internet-Draft；正式发布后将取代 RFC 8725，并更新 RFC 7519。
  • 最关键的运行要求不是“所有 JWT 都验签”，而是让不同令牌种类的验证规则互不重叠。类型、签发方、受众、必需声明、受保护头、算法、密钥与应用上下文必须共同限定授权范围。

告警令牌走到了支付接口

设想同一平台有两个入口。一个接收 Security Event Token，用来报告账户风险事件；另一个是支付 API，只接受访问令牌。两边信任同一签发方，也从同一地址取得公钥。某个真实、签名完全正确的事件令牌被送到支付接口，通用 JWT 组件返回“验证成功”。

密码学没有出错，权限判断却错了。

这是假设性的边界测试，不是已披露事故。它呈现了新版文档重点处理的跨 JWT 混淆：攻击者不必伪造签名，只要把为用途 A 签发的对象送进用途 B，而接收方又把“来源可信”误当成“可以在这里行使权力”。

因此，改用更长的密钥并不能修复问题。事件接收器和支付 API 必须拥有彼此排斥的验证规则。即使两种令牌采用同一种封装、来自同一机构、共享部分声明名称，它们也不能互换。

批准、编校与部署是三件事

IESG 公告记录，OAuth 工作组的“JSON Web Token Best Current Practices”第 10 版于 8 月 24 日 18:02 UTC 获批，目标状态是 Best Current Practice。

截至 8 月 28 日，Datatracker 仍把它列为活跃 Internet-Draft：文档日期为 8 月 21 日，页面在 25 日更新，失效日为 2027 年 2 月 22 日。IESG 状态为 RFC Ed Queue；RFC Editor 因尚未收到某项引用而标记阻塞。IANA 表示无需新增注册动作，但处理状态仍在进行。

这些时间点不能压成一句“新 RFC 已落地”。IESG 批准是明确的标准进展，却不是 RFC 编号、完成的编校流程，更不是生产验证器已经升级的证据。若按当前说明发布，它会废止 RFC 8725，并更新 JWT 基础规范 RFC 7519。

“有效 JWT”至少包含四个判定

JWT 是声明格式，不是一种单一的安全状态。它可以由 JWS 签名，可以用 JWE 加密，也可以嵌套；某些明确允许的场景甚至可使用 unsecured JWT。以点号分隔的紧凑序列化也不等于 JOSE 定义的各种 JSON 序列化。

接收方应依次回答四个问题：

  1. 收到的对象是否严格符合该入口允许的序列化形式；
  2. 签名或认证加密是否使用接收方预先允许的算法与正确密钥通过验证；
  3. 它是否属于该入口准备消费的令牌种类；
  4. 它的声明是否在此时、针对该签发方、受众、主体与操作形成授权。

解密 JWE 不等于验证其中嵌套对象的签名；能解析紧凑格式不等于建立信任；JWS 验签成功也不等于所有共享密钥的服务都可以采用其中声明。前一阶段的成功不能替后一阶段作决定。

typ 的价值在于排除错误类别

当不同令牌可能混淆时，新版指南建议使用明确的 typ。RFC 8417 为 Security Event Token 提供了可识别的媒体类型，使接收器能在解释声明前先识别合同。通用值 JWT 则无此能力：它只说明容器属于 JWT，并没有说明是哪一种应用令牌。

仅检查类型还不够。新版要求不同令牌验证器的接受集合互斥。可以用不同的明确类型、不同的必需声明或取值、不同的受保护头、不同密钥、不同受众或不同签发方建立边界。

RFC 9068 规定了 OAuth 访问令牌的 JWT 画像，RFC 8417 规定了安全事件令牌。两者都可能真实且签名正确，但在法律意义和运行意义上不可替代。应用必须先选择画像，再赋予字段权限含义。

旧系统迁移需要分阶段。已有令牌可能根本不携带 typ，立即强制会造成中断。较稳妥的第一步是：只要字段出现，就必须等于预期值；同时统计缺失量，再推动签发方和消费方把明确类型变为必选。兼容性是需要测量的现状，不是接受矛盾类型的理由。

同属一家公司，不等于同一受众

iss 指明谁作出声明，aud 限定声明写给谁。接收方应在声明影响路由、权限或数据前，按当前令牌画像验证两者。

服务 A 与服务 B 即使归同一公司、使用同一身份提供方，也不是天然的同一受众。为事件接收器签发的令牌不能因为基础设施共用就成为 API 访问凭证。

sub 也没有脱离画像的统一含义。它在一种令牌中可代表用户，在另一种中可代表客户端或安全事件的对象。字段名相同，授权语义却由具体令牌合同决定。

令牌无权选择自己的验证政策

允许哪些算法，必须由接收方配置。头部的 alg 是待核对输入，不是令牌自行指定验证方式的授权。指南还要求一把密钥只对应一个算法，避免相同密钥材料在不兼容的规则间被重新解释。

kid、jku、x5u 等密钥选择字段也构成输入面。它们可能参与数据库查询或远程取钥；若直接拼接或任意访问，就会形成注入与服务端请求伪造风险。对象验签前，这些头部仍是攻击者输入；对象验签后，也不能因此给签发方无限的网络访问能力。

修订稿还纳入密码口令加密的最低迭代约束、JWE 解压上限，以及 RFC 9864 所定义的完全指定算法标识。这些控制针对资源耗尽与算法歧义，不应被“验签成功率”指标遗漏。

一次授权应留下怎样的证据

可审计链条至少包含：原始字节与序列化形式、入口与预期令牌画像、解析结果与受保护头、算法白名单、实际密钥及其唯一算法、密码学结果、明确类型、签发方、受众、必需声明与时间窗、需要时的重放或撤销状态、政策判断、请求动作及最终影响。

一条“JWT valid”日志把这些阶段压成无法复核的结论。它无法证明是否选中了正确画像，是否比较了受众，也无法证明成功验证最终造成了什么动作。

运行代码优先的纪律正适用于这里：规范给出最小边界，生产系统必须用真实替换测试证明错误种类被拒绝，且下游没有发生任何效果。

来源