摘要

  • RIPE NCC的2026年第三季度计划把网页认证迁移称为OIDC 2.0：从全站安全cookie转向OIDC会话。但现行身份标准是构建在OAuth 2.0之上的OpenID Connect 1.0，公开记录需要把真实协议版本讲清楚。
  • OIDC能向应用证明登录身份，却不能凭一段有效会话授予全部对象的修改权。RIPE Database文档把认证、授权与凭据分开，并由mntner关系决定更新权限。
  • 结案记录应连接协议配置、会话寿命、登出、旧cookie停用、mntner查询、API密钥处理、允许与拒绝测试、回退边界和验收责任，同时不公开任何账户或凭据秘密。

一句计划文字里的三层状态

RIPE Database季度计划在2026年6月11日更新。第三季度第二项工作的标题是“将DB网页应用切换到OIDC 2.0”，正文说要把交互式用户认证从全站安全cookie换成OIDC 2.0会话，以提升已认证请求的安全性。项目状态仍是进行中。

这段话看起来只是在更换登录机制，实际上叠放了三种状态。第一种是身份提供方是否完成了认证。第二种是RIPE Database网页应用是否建立并继续接受本地会话。第三种是已认证身份是否满足某个对象的维护者保护条件。三种状态可能同时为真，也可能只完成其中一两种。只有最后一种状态决定一项具体更新有没有权力依据。

先承认计划的价值。把身份认证交给明确的联合登录机制，可以让RIPE NCC Access统一执行账户政策，使应用更清楚地检查签发者、受众、新鲜度和身份信息，也能减少某个旧式全站cookie承担过多含义。对用户而言，入口更一致；对工程团队而言，身份组件更容易独立维护。这些收益并不因为我们要求一份严格验收记录而减少。

真正需要修正或解释的是版本名称。OpenID Connect Core的正式名称是1.0，它在OAuth 2.0之上提供身份层。OpenID Connect的会话管理、前端登出、后端登出和依赖方发起登出又是各自独立的规范。查阅到的标准集合中没有一份名为OIDC 2.0的最终规范。

这不等于证明RIPE NCC写错了。OIDC 2.0可能是“OpenID Connect运行在OAuth 2.0之上”的内部简称，也可能是项目标签或普通笔误。公开资料没有给出答案。可验收性问题在于：测试人员无法从这个组合名称得知应当检查哪一种流程、哪一个签发者、哪一个客户端标识、哪些声明、怎样的令牌有效期，以及采用哪一种登出语义。协议名只有落实到版本和配置，才能成为操作指令。

换掉旧cookie不代表应用不再保存会话

季度计划把“全站安全cookie”与“OIDC会话”并列，很容易让读者以为cookie这种状态载体会被协议彻底取代。浏览器应用通常没有这么简单。身份提供方完成OpenID Connect认证后，依赖方应用仍可能创建自己的本地会话，并用一个范围更窄、属性不同的cookie向浏览器表示这段会话。身份提供方本身还保留另一段登录状态。

OpenID Connect Session Management之所以单独存在，就是因为首次认证响应之后仍有会话需要管理。RP-Initiated Logout又单独规定依赖方如何请求身份提供方结束用户会话。这些规范并不保证本地应用会话与身份提供方会话在同一秒结束，也不强迫所有实现采用同一种cookie或登出方式。工程团队必须选择具体边界，并证明选择得到执行。

因此，切换期间至少有四只时钟。身份提供方认证有一只，令牌有效期有一只，网页应用本地会话有一只，mntner授权关系何时被读取还有一只。用户点击本地退出、身份提供方退出、账户被停用、用户被移出维护者、API密钥过期、应用版本回退，都是不同事件。它们可以最终都让操作失败，却未必沿着同一条路径传播。

想象一个不带指控的例子：新入口启用前一分钟产生的旧cookie，为避免打断编辑，被允许再使用二十分钟。这可能是审慎的连续性安排，也可能不符合选定的安全政策。另一种方案是在切换瞬间注销所有用户，它更容易证明旧状态清零，却会增加支持负担并中断合法工作。文章不替RIPE NCC选择方案；它要求记录哪个方案实际被选中、何时结束、谁可以回退。

登录身份不是对象权限

RIPE Database的授权文档提供了最清楚的分界。认证用于确认行为者所声称的身份；授权是作出决定或取得访问的权力；凭据则为相信行为者有权行使这种权力提供依据。文档还说明，数据库的数据模型并不总能把所有凭据直接连接到可识别的个人，mntner对象保存SSO账户或密码学密钥等凭据引用。

这意味着OIDC返回的身份只能走到授权门口。网页应用接收身份之后，仍要找出保护目标对象的mntner，检查这段身份是否符合其auth条件，再决定允许或拒绝操作。一个账户可能关联多个维护者，不同对象也可能引用不同维护者。会话有效不能推出“对全部对象有效”。

API密钥文档把这个链条写得更具体。数据库API密钥属于RIPE NCC Access账户。使用密钥认证更新之前，该账户必须已经通过auth: SSO属性关联到mntner。创建密钥时还可以把密钥限制到一个特定维护者。密钥具有最长一年有效期、最近成功使用时间以及即时撤销功能。这些是凭据管理能力，不是普遍授权。

RIPE-843又规定了账户层面的纪律：RIPE NCC Access账户必须启用双因素认证，用户名应当由一个人使用，API密钥最长存活一年；关联SSO账户停用，或者用户在相应业务应用数据库中不再担任账户维护者时，密钥也会停用。于是，账户状态、凭据状态与对象授权形成了一条依赖链。OIDC迁移只有保持这条链，才能被称为认证改进而不是权限语义漂移。

2025年的公开代码提供了反例测试

RIPE-NCC/whois公共仓库的变更记录在1.117版本写下Support OAuth 2.0 (#1688)。编号1688的合并请求题为Support oauth2，在2025年3月3日合并。公开文件列表显示，它加入了Bearer令牌相关过滤和一套很长的集成测试。

最有价值的不是成功用例，而是两个拒绝用例。一种情况下，Bearer令牌关联的维护者与目标对象需要的维护者不同；另一种情况下，维护者看似相同，但SSO身份不匹配。测试期待服务器拒绝更新，并进一步确认对象属性没有被改变。换句话说，代码测试没有把“令牌可验证”当成“操作有权限”，也没有把错误响应当成足够的无副作用证据。

这份2025年证据不能用来宣布2026年的网页会话项目已经完成。前者是Whois服务的Bearer认证路径，后者是交互式网页应用的OIDC会话；时间、接口和状态都不同。它的正确用途是为验收设计提供一个成熟模式：同时检查允许和拒绝，并把数据库无变化作为拒绝成功的一部分。

一张双栏切换凭证

RIPE NCC不需要公开内部拓扑或账户信息，就能让迁移可审计。最紧凑的做法是一张双栏凭证。左栏记录身份与会话，右栏记录对象授权，中间用匿名测试编号连接。

身份与会话栏应写明实际采用的OpenID Connect Core和OAuth版本、配套规范、身份提供方与依赖方类别、授权流程、关键校验类别、本地会话创建规则、空闲与绝对寿命、刷新条件、登出路径、旧cookie最后接受时间、切换时已有会话的处理、观察窗口和回退点。这些字段都能在不泄露具体令牌或cookie值的前提下公开。

对象授权栏应记录身份如何解析、auth: SSO与mntner关系在哪个阶段读取、账户停用或维护者移除如何影响已存在会话、API密钥是否沿用相同时间线、测试了哪些对象与操作类别、允许用例的结果、拒绝用例的结果、被拒绝对象是否保持不变，以及由哪个角色接受结案。

这张凭证还能温和地解决OIDC 2.0问题。如果它只是内部简称，RIPE NCC可以说明它实际指OpenID Connect Core 1.0、OAuth 2.0以及哪些登出与会话规范；如果它是笔误，则可更正文档并保留更正链接。两种做法都比让后来的工程师从项目昵称猜协议更可靠。

不能从来源推出什么

公开来源没有给出此项目的签发者、客户端、流程、作用域、身份声明、令牌寿命、cookie属性、登出机制、上线日期、兼容期或回退规则。它们没有说明API密钥是否随网页会话迁移而变化，也没有证明OIDC 2.0一定是错误。

没有证据表明当前系统存在不安全cookie、失效会话、账户入侵、维护者误绑定、未授权更新、数据丢失或服务中断。2025年的Bearer实现也不能充当2026年网页项目的完成证明。本文提出的双栏凭证是编辑性的控制设计，不是声称RIPE NCC已经负有某项新义务。

因此，结论应保持窄而清楚：改进登录是有价值的，但项目结案必须证明真实协议、会话终止和mntner授权测试彼此相接。只有这样，未来审阅者才能分辨“谁登录了”“哪段状态还活着”和“谁有权改这个对象”。

来源