Zusammenfassung

  • Der Q3-Plan 2026 der RIPE Database sieht vor, die interaktive Anmeldung von einem siteweiten sicheren Cookie auf eine „OIDC 2.0 session“ umzustellen; der Eintrag steht weiterhin auf „In progress“.
  • OpenID Connect bestätigt eine Identität, ersetzt aber nicht die Autorisierungsentscheidung der Datenbank: Für eine Objektänderung bleibt die Verbindung zwischen SSO-Konto, Zugangsmittel und dem zuständigen mntner maßgeblich.
  • Ein belastbarer Abschlussnachweis sollte das tatsächlich eingesetzte OIDC/OAuth-Profil, den lokalen Sitzungszyklus, den alten Cookie-Schnitt, Logout, API-Schlüssel sowie erlaubte und verweigerte Maintainer-Fälle zusammenführen, ohne Geheimnisse offenzulegen.

Der falsche Endpunkt einer Migration

Die sichtbare Erfolgsmeldung nach einer Anmeldung ist ein verführerischer Endpunkt. Sie beantwortet jedoch nur, ob ein Identitätsanbieter und eine Anwendung sich über eine Identität verständigt haben. Sie beantwortet nicht, wie lange der Browserzustand in der Anwendung gilt. Und sie beantwortet erst recht nicht, ob die Identität jene Berechtigung besitzt, die das Schutzmodell der RIPE Database für eine konkrete Änderung verlangt.

Im Quartalsplan der RIPE Database steht diese Trennung noch nicht im Vordergrund. Der am 11. Juni 2026 aktualisierte Plan für das dritte Quartal führt als zweites Vorhaben „Switch DB web application to OIDC 2.0“. Die interaktive Web-Authentifizierung soll laut Beschreibung von einem siteweiten sicheren Cookie auf eine „OIDC 2.0 session“ wechseln. Der öffentliche Status lautet „In progress“. Das ist eine konkrete Arbeitsabsicht, aber weder ein Bereitstellungsnachweis noch eine vollständige Spezifikation der Abnahme.

Auch die Bezeichnung sollte nicht mehr tragen müssen, als sie kann. OpenID Connect Core 1.0 beschreibt OIDC als Identitätsschicht auf OAuth 2.0. Hinzu kommen veröffentlichte Spezifikationen für Session Management 1.0 und RP-Initiated Logout 1.0. In dieser geprüften Standardfamilie findet sich keine finale Spezifikation mit dem Namen „OIDC 2.0“.

Die Formulierung des Plans könnte eine Kurzform, ein internes Profil, ein redaktioneller Fehler oder eine Bezeichnung für eine bestimmte Kombination sein. Die öffentlichen Quellen entscheiden das nicht. Gerade deshalb wäre beim Abschluss eine genaue Profilangabe wertvoll: welche Version von OpenID Connect, welche OAuth-Ausprägung, welcher Flow und — sofern einschlägig — welche PKCE-Variante. Auch Aussteller und Relying Party beziehungsweise Client lassen sich auf sicherem Konfigurationsniveau benennen, ohne Token, Cookies, Kontokennungen oder interne Topologie zu veröffentlichen.

Es geht nicht darum, ein Ticket sprachlich zu korrigieren. Ein prüfbarer Protokollname verhindert vielmehr, dass zwei unterschiedliche Implementierungen später unter demselben Etikett rekonstruiert werden müssen. Eine Versionsangabe ist der Anfang des Nachweises, nicht sein Ersatz.

Die Anwendung behält einen eigenen Zustand

OpenID Connect macht aus einer Webanwendung keinen zustandslosen Empfänger. Die Session-Management-Spezifikation unterscheidet den Login-Zustand beim OpenID Provider vom Zustand der Relying Party. RP-Initiated Logout beschreibt, wie die Relying Party einen Abmeldevorgang beim Provider anstoßen kann. Die Anwendung muss trotzdem festlegen, wann sie ihre lokale Sitzung erzeugt, wie lange diese bei Inaktivität und insgesamt lebt, wie eine Erneuerung wirkt und was beim lokalen oder providerweiten Logout gelöscht wird.

Darum braucht die Umstellung einen zeitlichen Schnitt. Ab welchem Zeitpunkt wird das alte Cookie nicht mehr akzeptiert? Werden bereits laufende Sitzungen beendet, bis zu einem Ablaufdatum geduldet oder in einen neuen Zustand überführt? Beendet eine Abmeldung in der RIPE Database nur deren lokale Sitzung, zusätzlich die Sitzung beim Provider oder beides? Wie verhält sich eine Kontosperre zu einem Browser-Logout und wie unterscheidet sie sich von der Sperrung eines maschinellen Schlüssels?

Der Plan nennt diese Einzelheiten nicht. Die untersuchten Quellen belegen weder eine derzeit veraltete Live-Sitzung noch eine Schwachstelle, eine Kontoübernahme oder einen unbefugten Update-Vorgang. Das Fehlen eines öffentlichen Details ist kein Beweis eines Fehlers. Es bedeutet aber, dass ein späterer Abschlussstatus allein nicht verrät, welche Sitzungspopulation tatsächlich aus dem Verkehr gezogen wurde.

Eine Abnahme sollte daher mehrere Ereignisse getrennt beobachten: erfolgreiche Authentifizierung beim Provider, Anlage der lokalen Sitzung, Erneuerung, Ablauf, lokaler Logout, Logout beim Provider und Ablehnung eines Zustands jenseits der Schnittgrenze. Wer nur den ersten Login testet, misst die Tür, nicht das Gebäude dahinter.

mntner entscheidet über das Objekt

Die Autorisierungsdokumentation der RIPE Database liefert das passende Begriffsgerüst. Sie trennt Authentifizierung, Autorisierung und Zugangsmittel. Eine authentifizierte Person kann ein Zugangsmittel erhalten, das Zugriff autorisiert. mntner-Objekte enthalten ihrerseits Zugangsmittel wie SSO-Konten oder Verweise auf kryptografische Schlüssel und schützen damit Datenbankobjekte.

Eine gültige OIDC-Sitzung ist deshalb keine allgemeine Änderungsbefugnis. Nach der Identitätsprüfung muss die Anwendung das einschlägige SSO-Konto und dessen Verbindung zum richtigen Maintainer auflösen. Dann muss sie die Schutzbeziehung des Zielobjekts und die konkrete Operation bewerten. Eine erlaubte Aktualisierung und eine verweigerte Aktualisierung durch eine ebenso gültig angemeldete, aber dem falschen mntner zugeordnete Identität gehören beide in die Abnahme.

Für diese Unterscheidung gibt es bereits öffentliches Material aus einem verwandten, aber nicht identischen Pfad. Der Pull Request RIPE-NCC/whois #1688 mit dem Titel „Support oauth2“ wurde am 3. März 2025 zusammengeführt. Die öffentliche Dateiansicht des Pull Requests enthält negative Tests: Ein Bearer-Token mit dem falschen Maintainer oder der falschen SSO-Identität wird zurückgewiesen; das Datenbankobjekt bleibt unverändert. Die öffentliche changes.txt verzeichnet „Support OAuth 2.0 (#1688)“ für Release 1.117.

Das ist starke Evidenz für eine schmale Aussage. Token-Authentifizierung und Objekt-Autorisierung werden als getrennte Prüfungen behandelt. Es ist keine Evidenz dafür, dass das 2026 geplante OIDC-Sitzungsprojekt für den Browser bereits ausgerollt wurde. Der Pull Request betrifft Bearer-Token, stammt aus einem anderen Jahr und trägt einen anderen Oberflächenbezug. Die beiden Linien sollten verbunden, aber nicht gleichgesetzt werden.

API-Schlüssel laufen auf einer anderen Uhr

Die Dokumentation der API-Schlüssel zeigt, weshalb ein globales Wort wie „Authentifizierung“ für die Migration zu grob ist. Ein Datenbankschlüssel gehört zu einem RIPE-NCC-Access-Konto. Damit Änderungen erlaubt werden, muss dieses Konto über ein Attribut auth: SSO mit einem mntner verbunden sein. Ein Schlüssel kann außerdem auf genau einen Maintainer begrenzt werden. Ablaufdatum, letzte Nutzung und sofortiger Widerruf sind dokumentierte Bestandteile des Lebenszyklus.

RIPE-843 ordnet diese Mechanik in die Kontosicherheit ein. Das Dokument verlangt Zwei-Faktor-Authentifizierung, sieht einen Benutzernamen für eine Person vor, begrenzt die Lebensdauer eines API-Schlüssels auf ein Jahr und hält fest, dass die Deaktivierung eines SSO-Kontos oder die Entfernung eines Nutzers als Account-Maintainer den zugehörigen Schlüssel deaktiviert.

Aus diesen Regeln folgt nicht, dass der Browserwechsel die Schlüssel verändert. Ebenso wenig folgt, dass beide Pfade völlig unabhängig sind. Die korrekte Schlussfolgerung ist enger: Der Übergangsnachweis muss die API-Schlüssel ausdrücklich einordnen. Bleiben sie unverändert, ist das eine dokumentierte Kontinuität. Ändert sich eine Abhängigkeit, braucht sie einen eigenen Test und möglicherweise eine andere Beobachtungsfrist.

Was in einen Übergangsbeleg gehört

Ein brauchbarer Beleg wäre keine Architektur-Enzyklopädie. Er könnte auf einer Seite die tatsächlich akzeptierten OIDC- und OAuth-Versionen, Flow und Profil festhalten. Danach kämen die Regeln für die lokale Sitzung: Erzeugung, Leerlaufgrenze, absolute Laufzeit, Erneuerung und die Wirkungen der verschiedenen Logout-Wege. Eine präzise Uhrzeit oder Release-Grenze würde festlegen, wann der frühere Cookie-Zustand nicht mehr akzeptiert wird und wie bestehende Sitzungen behandelt werden.

Der zweite Teil würde Identität und Befugnis verbinden. Er beschriebe die Auflösung vom SSO-Konto zum mntner auf funktionaler Ebene, dokumentierte repräsentative erlaubte und verweigerte Änderungen und bestätigte beim negativen Test die Unverändertheit des Objekts. API-Schlüssel, Testdatenbank, Ausnahmezahl, Beobachtungsfenster und Rückrollgrenze würden jeweils ausdrücklich ein- oder ausgeschlossen.

Am Ende stünden Datum und zuständige Abnahmefunktion. Spätere Korrekturen würden angehängt, anstatt die ursprüngliche Aussage still zu überschreiben. Das ist Theo Marchs vorgeschlagener Kontrollbeleg, keine Behauptung über eine bereits vorhandene RIPE-NCC-Funktion oder eine öffentlich zugesagte Pflicht.

Sensible Werte gehören nicht hinein. Token, Cookies, E-Mail-Adressen, Maintainer-Geheimnisse, private Objektinhalte und interne Netzpläne bleiben verborgen. Öffentlich wird die Kette der Entscheidungen, nicht das Material, mit dem sich diese Entscheidungen missbrauchen ließen.

Quellen