要約

  • RIPE NCCの2026年第3四半期計画は、RIPE Databaseの対話型認証をサイト全体の安全なCookieからOIDC 2.0セッションへ移すとしている。しかし確認できる標準は、OAuth 2.0上のOpenID Connect 1.0である。
  • OIDCが証明する本人性と、特定オブジェクトを更新する権限は別の判断である。公開文書では、後者はSSOアカウントと資格情報を参照するmntnerの保護関係に残る。
  • 受入記録には、実際の標準プロファイル、ローカルセッション、ログアウト、旧Cookie停止、mntner照合、APIキー、許可・拒否試験、ロールバック、完了承認を結び付ける必要がある。

版番号を曖昧にしたまま試験はできない

RIPE Databaseの四半期計画は2026年6月11日に更新され、第3四半期の項目2を「DB WebアプリケーションをOIDC 2.0へ切り替える」とした。説明では、対話型利用者認証をサイト全体の安全なCookieからOIDC 2.0セッションへ移し、認証済みリクエストをより安全にすると述べる。状態は現在も進行中である。

目標には合理性がある。個別アプリケーションが独自に認証状態を解釈する範囲を狭め、RIPE NCC Accessを共通の本人確認点として利用すれば、発行者、対象、認証時点、アカウント状態をそろえて扱いやすい。利用者にとっても入口が一貫し、運用者にとっても認証機能をサービス本体から分離しやすくなる。

ただし、公開された名称は受入基準として不十分である。OpenID Connect Coreの標準名は1.0であり、OAuth 2.0の上に本人性の層を置く。セッション管理と、RPが開始するログアウトは、それぞれ別のOpenID Connect 1.0仕様である。調査した標準群にはOIDC 2.0という最終仕様は見当たらない。

この事実だけでRIPE NCCの誤りを断定するべきではない。名称は「OAuth 2.0上のOpenID Connect」を縮めた内部表現かもしれず、事業上の呼称かもしれず、単純な記載ミスかもしれない。公開情報からは区別できない。問題は、受入担当者がその名前から実装の義務を一意に導けないことにある。

どの認可コードフローを採用するのか、PKCEを求めるのか、どの発行者とクライアント識別子を信頼するのか、どのクレームをRIPE NCC Accessの本人性として受け取るのか、トークンとアプリ内セッションをいつ切るのか。ログアウトはローカルだけか、IDプロバイダーへ連動するのか。こうした問いは具体的な標準とプロファイルがあれば試験できる。混成した版番号では試験表を作れない。

OIDCの後にもローカルセッションは残り得る

計画文は旧CookieとOIDCセッションを対比するため、OIDCへ移ればCookieという状態が消えるようにも読める。だがWebアプリケーションでは、OpenID Providerが認証を終えた後、Relying Partyが独自のローカルセッションを作ることが多い。そのセッションをブラウザーに示す手段が、範囲や属性を改めた別のCookieであることも珍しくない。さらにプロバイダー側には別のログイン状態がある。

OpenID Connect Session Managementが独立した仕様であるのは、最初の認証応答だけで状態管理が終わらないからだ。RP-Initiated Logoutも、Relying PartyからOpenID Providerへ終了を求める仕組みを別に定めている。プロバイダーでのログアウト、アプリ内セッションの破棄、トークン失効は関連するが、必ず同じ瞬間に起きるとは限らない。

移行期には少なくとも四つの時計がある。プロバイダーの認証状態、発行されたトークンの有効期間、RIPE Database Webアプリのローカルセッション、そして更新時に参照されるmntner権限である。アカウント無効化、Maintainerからの削除、APIキー失効、旧版への切戻しも、それぞれ違う起点を持つ。

例えば切替直前に作られた旧Cookieを、作業中断を避けるため三十分だけ受け入れる設計はあり得る。反対に、切替時に全員の再ログインを求める設計もある。前者は継続性を高める代わりに二つの失効時計を持ち、後者は状態を整理する代わりに利用者負担を増やす。どちらが常に正しいという話ではない。採用した境界、終了時刻、例外、切戻し条件を記録できるかが問われる。

認証と更新権限を分ける公開モデル

RIPE Databaseの文書は、認可、認証、資格情報を区別している。認証は行為者が名乗る本人かを確かめる。認可は意思決定やアクセスを行う力である。資格情報は、その力を行使できると信頼する根拠になる。似た語を分けていること自体が、今回の移行を理解する手掛かりになる。

オブジェクトの保護ではmntnerが中心にある。mntnerはSSOアカウントや暗号鍵参照などの資格情報を保持する。OIDCセッションが正しい本人性をアプリへ届けても、その本人が任意のオブジェクトを変更できるわけではない。対象オブジェクトを保護するmntnerを解決し、該当するauth条件と本人性を照合して初めて、特定操作の許可が決まる。

APIキーの文書は境界をさらに具体化する。Database APIキーはRIPE NCC Accessアカウントに結び付く。更新認証に使う前に、そのアカウントはauth: SSOによってmntnerへ関連付けられていなければならない。キーを一つのMaintainerへ限定することもできる。キーには期限、最終利用表示、即時失効があるが、それらは資格情報の性質であり、全オブジェクトへの包括権限ではない。

RIPE-843はアカウント側の規律を定める。二要素認証を必須とし、利用者名は一人のためのものとし、APIキーの寿命を最長一年にする。またSSOアカウントが無効になった場合や、該当する業務アプリのアカウントMaintainerから利用者が外れた場合、関連キーを無効にするとしている。本人性、資格情報、オブジェクト権限はここでも鎖になっており、一つの状態ではない。

2025年のBearer対応から読めること

公開リポジトリーRIPE-NCC/whoisの変更履歴は、版1.117にSupport OAuth 2.0 (#1688)を記録する。プルリクエスト1688はSupport oauth2という題で2025年3月3日にマージされた。公開差分にはBearer認証のフィルターと大規模な統合試験が含まれる。

重要なのは拒否試験である。Bearerトークンが対象オブジェクトとは異なるMaintainerに結び付く場合、更新は拒否される。Maintainerが同じように見えてもSSO本人性が異なる場合も拒否される。さらに試験は、拒否後にオブジェクトの属性が変わっていないことを確認する。つまり「認証できた」と「更新できる」を別判定にし、エラー表示だけでなく副作用がないことまで証明している。

この実装は今回の設計に有用な先例だが、2026年のWebセッション移行の完了証明ではない。2025年の変更はWhoisサービスへ届くBearer経路であり、四半期計画は対話型Webアプリの認証とセッションを扱う。日付、入口、保存状態が違う。隣接する成果を流用して別作業を完了扱いにすれば、かえって境界が消える。

二段の受入証跡

公開可能な受入証跡は二段で構成できる。第一段はプロトコルとセッションである。実際に採用したOpenID Connect Core、OAuth、セッション、ログアウト仕様を正確に示す。秘密を出さずに、発行者とクライアントの分類、フロー、検証項目、ローカルセッション生成、アイドル期限と絶対期限、更新条件、ログアウト経路、旧Cookie受入終了、既存セッションの扱い、監視期間、切戻し点を記録する。

第二段は権限である。SSO本人性をどの段階でmntnerへ照合するか、Maintainerからの削除やアカウント無効化が開いているセッションへいつ届くか、APIキーは同じ時計か別の時計かを示す。許可対象と拒否対象のオブジェクト・操作分類、結果、拒否後の不変性、例外数、完了承認者も含める。

利用者メール、トークン、Cookie、鍵、秘密のオブジェクト内容、内部構成を公開する必要はない。匿名化した試験番号、関係の分類、版、時刻、判定、結果ハッシュだけで十分である。訂正が起きたら古い証跡を上書きせず、新しい版を追記する。そうすれば監査可能性とプライバシーは両立する。

断定してはいけないこと

公開資料は、この移行の発行者、クライアント、フロー、スコープ、クレーム、トークン寿命、Cookie属性、ログアウト方式、稼働開始日、互換期間、回復手順を示していない。OIDC 2.0が誤記なのか内部名称なのかも不明である。APIキーが今回の切替で変わるとも書いていない。

現在のCookieが危険である証拠、終了しない実セッション、アカウント侵害、Maintainer誤関連、権限のない更新、データ損失、停止事故はいずれも確認されていない。提案する証跡は、存在する障害の告発ではなく、作業を何で完了とするかを事前に定義する統制案である。

結論は限定的でよい。RIPE NCCは認証を近代化できる。ただし完了を名乗るときは、実際の標準、セッション終了、mntnerの許可・拒否試験を一つの証跡でつなぐべきだ。新しいログインは入口を改善する。権限の出所まで説明できてこそ、入口の改善が長く信頼できる。

情報源