摘要

  • NIST 于 2026 年 9 月 15 日发布 IR 8587 最终版，面向联邦机构及其云服务商；除非其他政策或协议赋予约束力，遵循该指南本身是自愿的。
  • 最终版并不把“已撤销”视为所有依赖方即时拒绝令牌的证明。无状态访问令牌可能要等到有效期结束；服务商须说明撤销范围和方法，使用机构须评估相应情景的风险。
  • 与 2025 年 12 月草案相比，最终版把撤销状态向关联系统传播的无条件 MUST，改成提供传播手段的 SHOULD，并把依赖方拒绝令牌、终止会话的 MUST 置于“能力可用”这一前提下。

一次身份凭据泄露之后，运维人员可能先在签发系统中撤销身份或停用刷新令牌。这会阻止新的凭据继续产生，却不一定改变远端资源服务对旧访问令牌的判断。若资源服务只检查签名、目标受众和到期时间，签发端的动作与资源端的拒绝并非同一事件。把它们写成一条已经闭合的时间线，会低估需要处置的剩余窗口。

NIST 的《防止令牌与断言遭伪造、盗窃和滥用》最终版正面承认这个限制：无状态实现未必能在有效期结束前即时、全局撤销令牌。缩短访问令牌寿命，配合刷新控制或重新认证，可以压缩风险暴露，却不能自动证明每个已签发令牌已被收回。报告建议身份和访问令牌的有效期不超过一小时，同时建议云服务商允许使用机构依据风险配置该时长。这里的 SHOULD 是指南的推荐，不是某一家云服务目前实际采用的期限。

报告给出一张软件即服务的责任示例表：核心身份管理、令牌签发与签名主要由服务商承担；身份管理策略与应用访问由使用方配置；事件响应、持续监测和令牌撤销则列在双方名下。表格不是一份通用合同。实际边界受服务模式、合同条款和技术能力影响，因此“谁能撤销”必须进一步问到“撤销哪一种令牌、影响哪些服务、需要多久”。

定稿与草案的差异值得准确阅读。2025 年草案已经写明无状态令牌的困难，也已经要求服务商告知撤销方法、机构评估风险；这些不是今年 9 月才出现的新发现。草案另要求令牌服务确保身份令牌或断言的撤销状态传播到关联系统。最终版改为建议令牌服务提供向相关依赖方传播状态的手段；若该能力存在，连接的依赖方才须拒绝已撤销令牌并结束对应会话。最终版举出令牌内省、状态列表、共享信号，并加入 Shared Signals Framework 和 Continuous Access Evaluation Profile 的讨论。这些路径可供设计选择，不能证明所有服务都已接入。

定稿保留了一组关键的双向责任：云服务商须向使用机构说明撤销的范围与方法，机构须在集成时评估撤销情景的风险和影响。报告中大写的 MUST 是符合该指南的规范用语；NIST 同时明确指出，若无外部政策或有约束力的协议，符合指南是自愿的。因而本文不把技术建议说成对所有企业直接生效的法律命令，也不臆测任何具体供应商的缺口。

对采购、集成和事故指挥而言，关键问题不是控制台是否显示“撤销成功”，而是该成功表示停止签发、拒绝刷新、向依赖方发出信号、终止活跃会话，还是等待旧访问令牌自然过期。最终版提及的 IETF Token Status List 仍是 OAuth 工作组采纳的 Internet-Draft，Global Token Revocation 仍是个人 Internet-Draft；两者不能写成已完成的标准，更不能替代对实际部署的核实。

来源