Zusammenfassung

  • Der individuelle Entwurf vom 28. Oktober schlägt zwei einander ausschließende OAuth-Metadaten vor: client_ip_ranges nennt IPv4- und IPv6-Präfixe direkt, client_ip_ranges_uri verweist auf ein JSON-Dokument per HTTPS. Registrierung oder Abruf der Liste ist noch keine Annahme ihrer Bereiche.
  • Scheitert der Abruf, ist das Dokument ungültig oder zieht der Client seine Erklärung zurück, dürfen bislang gesperrte Adressen dadurch nicht frei werden. Der Server kann die bisher angenommene Liste behalten, sie auf die Schnittmenge mit einem geprüften Ersatz verkleinern und eine Frist setzen. Nach Fristende weist ein Server, der die Regel durchsetzt, den Client bis zur neuen Annahme oder einer ausdrücklichen Entscheidung gegen die Durchsetzung ab.

Die neue Adresse wartet vor dem Tor

Ein Unternehmen verlegt seinen OAuth-Client zu einem anderen Cloud-Ausgang. Die neue JSON-Datei liefert HTTP 200. Der Token-Endpunkt erkennt dennoch nur die früheren Absender. Der Entwurf macht diese Lücke ausdrücklich: Herunterladen heißt nicht genehmigen. Der Server prüft den vollständigen Satz und entscheidet nach eigener Richtlinie, ob eine Erweiterung zulässig ist. Ein ungewohnt großes Präfix darf nicht allein durch eine Dateiversion zum Eintrittsschein werden.

Der Client kann Präfixe unmittelbar in den Metadaten nennen oder auf ein HTTPS-Dokument zeigen. Beides zugleich ist unzulässig. Fehlen beide Felder, liegt keine Erklärung vor; ein leeres Array erklärt eine leere Menge. Gegenüber der Aktualisierung nach RFC 7592 ist das eine wichtige Unterscheidung: Das leere Array darf nicht als Löschbefehl für das Feld behandelt werden. Wird die leere Menge angenommen und durchgesetzt, kommt keine Quelladresse hinein.

Eine angenommene neue Liste ersetzt die alte vollständig. Der Entwurf kennt kein schrittweises Hinzufügen. Wartet ein gültiger Ersatz noch auf Zustimmung, kann der Server die bestehende Menge auf die Schnittmenge beider Listen beschränken. So schließt er einen verlassenen Ausgang, bevor er einen neuen freigibt. Der Client sollte eine neue Adresse vor dem Verkehrswechsel anmelden und die alte so lange nennen, wie darüber noch Anfragen laufen. Abrufintervall und Genehmigungszeit gehören in denselben Migrationsplan.

Ein defektes Dokument öffnet nicht plötzlich alle Schranken. Abruffehler, ungültige Angaben und auch der Rückzug der Erklärung dürfen vorher abgewiesene Quellen nicht automatisch zulassen. Eine Lockerung nach Rückzug braucht einen ausdrücklichen lokalen Beschluss. Der Server sollte begrenzen, wie lange die alte Menge während Fehlern, Rückzug oder ausstehender Genehmigung gilt. Danach muss ein durchsetzender Server Anfragen verweigern, bis er unter der aktuellen Erklärung eine Menge annimmt oder die Durchsetzung ausdrücklich beendet. Wiederholtes Prüfen eines unbestätigten Ersatzes stellt die Uhr nicht zurück.

Auch das Festhalten hat Risiken. Eine aufgegebene IP-Adresse kann einem anderen Nutzer zugeteilt werden. Die Schnittmenge und die Frist verkürzen die Zeit, in der sie noch als Quelle durchgeht. RFC 9111 regelt HTTP-Caches; die angenommene IP-Menge ist im Entwurf ein eigener Anwendungszustand. Ein 304 Not Modified bestätigt eine gespeicherte Antwort, aber keine politische Zustimmung. Ablauf eines Cache-Eintrags beendet ebenso wenig von selbst die alte Annahme.

Eine Firewall vor dem Endpunkt sieht Adressen, nicht den einzelnen OAuth-Client. Sie kann nur einen gemeinsamen Bereich mehrerer Clients anwenden. Erst nach Identifizierung kann der Autorisierungsserver eine individuelle Menge durchsetzen. Eine passende IP authentifiziert den Client nicht. Selbst eine signierte Erklärung, die nur die Dokument-URL enthält, bürgt für diese URL, nicht für künftige Inhalte des Hosts. Der Hoster kann den Client durch eine leere Liste oder dauerhafte Nichterreichbarkeit aussperren.

Der IETF-Eintrag nennt einen individuellen Vorschlag ohne gemessenes Betriebsergebnis. Ein Migrationstest müsste die abgerufene Version, die wirklich angenommene Menge, den Zeitpunkt der Freigabe, das Ende der alten Adressen und die Entscheidungen des Token-Endpunkts zeigen.

Quellen: Entwurf; IETF-Status; RFC 7592; RFC 9111.