Zusammenfassung

  • RFC 9728 beschreibt, wie eine geschützte Ressource Metadaten veröffentlicht; das Dokument informiert über einen möglichen nächsten Schritt, gewährt aber keinen Ressourcenzugriff.
  • Erst die exakte Prüfung der Ressourcenkennung erlaubt die Nutzung der Metadaten. Ausstellung, Annahme und Wirkung eines Tokens bleiben danach getrennte Entscheidungen.

„Der richtige Autorisierungsserver steht in den Metadaten“ klingt wie eine fertige Berechtigung. Tatsächlich kann damit nur feststehen, dass ein Client ein JSON-Dokument gefunden hat, das einen möglichen Issuer nennt. Ob dieser Issuer ein Token ausstellt, ob dieses Token für genau diese Ressource gilt und ob die Ressource es akzeptiert, ist damit offen.

RFC 9728 begrenzt diese Aussage absichtlich. Die Ressource veröffentlicht ihre Beschreibung unter einer aus ihrer Kennung abgeleiteten .well-known-Adresse. Sie kann Autorisierungsserver, Scopes und Präsentationsmethoden nennen. Das erleichtert Interoperabilität, macht die Beschreibung aber nicht zur Entscheidung über einen konkreten Client oder Vorgang.

Die wichtigste Grenze ist die Identität der Ressource. Der verpflichtende Wert resource muss bei normaler Entdeckung exakt mit der Kennung übereinstimmen, aus der die Metadatenadresse abgeleitet wurde. Kam die Adresse aus WWW-Authenticate, muss er exakt der URL entsprechen, die der Client beim Resource Server aufgerufen hat. Bei Abweichung dürfen die Daten nicht verwendet werden. Ähnlichkeit von Hostnamen, Produktnamen oder Pfaden genügt nicht.

Das schützt gerade Mehrmandanten- und Pfadmodelle. Der Well-known-Suffix wird vor dem Ressourcenpfad eingesetzt, sodass mehrere Ressourcen auf einem Host unterschiedliche Metadaten führen können. Diese Veröffentlichung ist keine allgemeine Auskunft über den Host. Wer sie als globale Freigabeliste liest, verschiebt die Policy-Grenze, bevor ein Token angefordert wurde.

Auch veröffentlichte Listen sind nicht vollständig. authorization_servers ist optional und darf unterstützte Server auslassen; scopes_supported ist ebenfalls keine vollständige Anspruchsliste. Ein genannter Scope muss weiterhin angefordert, geprüft und in einem Token ausgegeben werden. Ein fehlender Eintrag beweist das Gegenteil nicht.

Signierte Metadaten stärken nur die Behauptung darüber, wer ein Metadatenbündel bestätigt. Sie ersetzen weder Client-Authentisierung noch Zustimmung, Token-Prüfung oder Geschäftsentscheidung. RFC 8414, RFC 8707 und RFC 6750 verteilen Serverbeschreibung, Ressourcenziel und Bearer-Präsentation bewusst auf verschiedene Prüfer. RFC 9728 verbindet diese Flächen nicht zu einer Autorität.

Sources