摘要

  • 2026 年 9 月 28 日首次提交的个人 Internet-Draft 提议由证明方分配 client_instance_id，在密钥更换得到验证时可沿用该实例标识。它尚非 RFC、工作组决议或落地部署。
  • 草案第 5.1 节明确：标识延续不会替旧的、绑定原密钥的刷新令牌重新绑定。按基础草案默认规则，用新密钥刷新仍会失败，除非另有适用规范改变令牌绑定方式。
  • 授权服务器还需核对当前有效证明里的实例身份与授予权限时记录的 Source Instance Identity；身份吻合与令牌的密钥证明合格，必须分别成立。

两道门，不能用一把钥匙解释

假设应用按计划轮换密钥。证明方检查换钥过程，认定新密钥属于原登记的客户端安装，并给出相同的实例标识。此时，授权服务器收到旧刷新令牌以及新密钥的证明。若系统只看标识是否相同，就可能把“安装实例未变”误读成“原有令牌可以由任意后继密钥使用”。这正是新草案要避免的控制跃迁。

K. McGuinness 的 -00 版提案把 client_instance_id 定位为身份与连续性证据，不是授予权限的凭据。它明确不创建按实例绑定的授权，也不改写已签发令牌的绑定。作为背景，基于证明的 OAuth 客户端认证基础草案默认将刷新令牌绑定到 Client Instance Key。更换该密钥后，旧令牌与新密钥不再满足原来的组合条件。即便证明方正确确认了安装的延续，授权服务器仍应拒绝这条默认绑定下的刷新请求。只有另一份适用的配置规则真正修改了绑定方式，结论才可能不同；本提案本身没有做这件事。

因此，两个相反的检查结果可以同时为真：实例身份匹配，旧令牌的密钥绑定失败。把前者覆盖后者，不是技术上的“容错”，而是未经明示地转移了旧授权。对于处理凭证轮换的团队，关键不只是让客户端恢复业务，而是明确恢复过程是否需要重新取得令牌、另设合规迁移规则或重新授权。草案没有自动选定任何一种。

为什么复制旧资料不等于继续原实例

提案要求标识不透明、难以猜测、不得重新分配。经认证的同一登记关系下换钥，可以保持标识；重装、独立克隆或产生新的执行单元则通常需要重新登记。将原密钥、应用数据与标识一起复制到另一处，不足以证明它是正当后继。即使从快照恢复，也需要新的、经认证的后继证据。这条界线阻止“我拥有旧材料”被直接当作“我就是旧安装”。它也意味着并非每次称作“轮换”的操作都应保留同一身份。

标识默认只在一个 Receiver 范围内有效，不是所有服务可共享的全球设备号。证明方与客户端要选择并遵守该范围；范围和密钥隔离若被实际部署忽略，跨服务关联风险会回来。草案同样不允许仅凭实例证明决定用户 sub、扩展代理 act 链或跳过持钥证明。可选的 client_instance 令牌或内省上下文，可以向资源服务器表达安装身份，却不自行增加权限。

对依该配置建立的授权，第 5.1 节还有一层约束：授权服务器在签发时记录 Source Instance Identity，刷新时验证一份当前证明，并比较其中的实例身份。若不一致，身份连续性这一关过不了；若一致，仍须按实际适用的密钥绑定规则审核旧令牌。这种双轨核对，比一个笼统的“证明成功”状态更能解释拒绝或接受的原因。

IETF Datatracker 条目目前把它列为首版个人 Internet-Draft，状态是 I-D Exists。文档注明预期走 Standards Track，并不等于已被 OAuth 工作组采纳或成为标准。现有一手资料也没有提供真实部署、互操作测试或安全事件的独立证据。这里讨论的是提案可能如何改变运营判断，而非宣称行业已这样运行。

来源