Zum Hauptinhalt springen

3. Obtaining Authorization Server Metadata (Abrufen der Autorisierungsserver-Metadaten)

Autorisierungsserver, die Metadaten unterstützen, müssen (MUST) ein JSON-Dokument mit den in Abschnitt 2 angegebenen Metadaten unter einem Pfad bereitstellen, der durch Einfügen einer bekannten URI-Zeichenfolge (well-known) zwischen der Host-Komponente und der Pfad-Komponente (falls vorhanden) des Aussteller-Identifikators des Autorisierungsservers gebildet wird. Standardmäßig wird die bekannte URI-Zeichenfolge /.well-known/oauth-authorization-server verwendet. Dieser Pfad muss (MUST) das "https"-Schema verwenden. Die Syntax und Semantik von ".well-known" sind in RFC 5785 [RFC5785] definiert. Das verwendete bekannte URI-Suffix muss (MUST) im IANA-Register "Well-Known URIs" [IANA.well-known] registriert werden.

Verschiedene Anwendungen, die einen OAuth-Autorisierungsserver auf anwendungsspezifische Weise verwenden, können (MAY) verschiedene bekannte URI-Suffixe definieren und registrieren, die zur Veröffentlichung der von diesen Anwendungen verwendeten Autorisierungsserver-Metadaten verwendet werden. Wenn beispielsweise eine Beispielanwendung einen OAuth-Autorisierungsserver auf beispielspezifische Weise verwendet und beispielspezifische Metadatenwerte veröffentlichen muss, könnte sie das URI-Suffix "example-configuration" registrieren und verwenden und das Metadatendokument veröffentlichen, indem sie /.well-known/example-configuration zwischen den Host- und Pfadkomponenten des Aussteller-Identifikators des Autorisierungsservers einfügt. Alternativ werden viele solcher Anwendungen die standardmäßige bekannte URI-Zeichenfolge /.well-known/oauth-authorization-server verwenden, die die angemessene Wahl für generische OAuth-Autorisierungsserver ist, und keine anwendungsspezifische Zeichenfolge registrieren.

OAuth 2.0-Anwendungen, die diese Spezifikation verwenden, müssen (MUST) angeben, welches bekannte URI-Suffix sie zu diesem Zweck verwenden werden. Derselbe Autorisierungsserver kann (MAY) wählen, seine Metadaten an mehreren bekannten Standorten zu veröffentlichen, die von seinem Aussteller-Identifikator abgeleitet sind, z. B. indem er sie sowohl bei /.well-known/example-configuration als auch bei /.well-known/oauth-authorization-server veröffentlicht.

Einige OAuth-Anwendungen werden das bekannte URI-Suffix "openid-configuration" verwenden. Wie in Abschnitt 5 erwähnt, bezieht sich die Verwendung des Identifikators /.well-known/openid-configuration in dieser Spezifikation, obwohl er OpenID-spezifisch erscheint, tatsächlich auf eine allgemeine OAuth 2.0-Funktionalität und ist nicht spezifisch für OpenID Connect.

3.1. Authorization Server Metadata Request (Autorisierungsserver-Metadatenanfrage)​

Das Autorisierungsserver-Metadatendokument muss (MUST) unter Verwendung einer HTTP-"GET"-Anfrage an den zuvor angegebenen Pfad abgefragt werden.

Wenn der Aussteller-Identifikator https://example.com ist und das bekannte URI-Suffix "oauth-authorization-server" ist, wird der Client die folgende Anfrage stellen, um die Metadaten zu erhalten, da der Aussteller-Identifikator keine Pfadkomponente enthält:

GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com

Wenn der Wert des Aussteller-Identifikators eine Pfadkomponente enthält, muss (MUST) jedes abschließende "/" entfernt werden, bevor /.well-known/ und das bekannte URI-Suffix zwischen den Host- und Pfadkomponenten eingefügt werden. Wenn der Aussteller-Identifikator https://example.com/issuer1 ist und das bekannte URI-Suffix "oauth-authorization-server" ist, wird der Client die folgende Anfrage stellen, um die Metadaten zu erhalten, da der Aussteller-Identifikator eine Pfadkomponente enthält:

GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com

Die Verwendung von Pfadkomponenten ermöglicht die Unterstützung mehrerer Aussteller pro Host. Dies ist in einigen Mandanten-Hosting-Konfigurationen erforderlich. Diese Verwendung von ".well-known" dient der Unterstützung mehrerer Aussteller pro Host; im Gegensatz zu seiner Verwendung in RFC 5785 [RFC5785] stellt sie keine allgemeinen Informationen über den Host bereit.

3.2. Authorization Server Metadata Response (Autorisierungsserver-Metadatenantwort)​

Die Antwort ist eine Menge von Ansprüchen über die Konfiguration des Autorisierungsservers, einschließlich aller erforderlichen Endpunkte und Standortinformationen für öffentliche Schlüssel. Eine erfolgreiche Antwort muss (MUST) den HTTP-Statuscode 200 OK verwenden und ein JSON-Objekt mit dem Inhaltstyp "application/json" zurückgeben, das eine Menge von Ansprüchen als seine Mitglieder enthält, die eine Teilmenge der in Abschnitt 2 definierten Metadatenwerte sind. Andere Ansprüche können (MAY) ebenfalls zurückgegeben werden.

Ansprüche, die mehrere Werte zurückgeben, werden als JSON-Arrays dargestellt. Ansprüche mit null Elementen müssen (MUST) aus der Antwort weggelassen werden.

Fehlerantworten verwenden anwendbare HTTP-Statuscodewerte.

Das Folgende ist eine nicht normative Beispielantwort:

HTTP/1.1 200 OK
Content-Type: application/json

{
 "issuer":
   "https://server.example.com",
 "authorization_endpoint":
   "https://server.example.com/authorize",
 "token_endpoint":
   "https://server.example.com/token",
 "token_endpoint_auth_methods_supported":
   ["client_secret_basic", "private_key_jwt"],
 "token_endpoint_auth_signing_alg_values_supported":
   ["RS256", "ES256"],
 "userinfo_endpoint":
   "https://server.example.com/userinfo",
 "jwks_uri":
   "https://server.example.com/jwks.json",
 "registration_endpoint":
   "https://server.example.com/register",
 "scopes_supported":
   ["openid", "profile", "email", "address",
    "phone", "offline_access"],
 "response_types_supported":
   ["code", "code token"],
 "service_documentation":
   "http://server.example.com/service_documentation.html",
 "ui_locales_supported":
   ["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}

3.3. Authorization Server Metadata Validation (Validierung der Autorisierungsserver-Metadaten)​

Der zurückgegebene Wert "issuer" muss (MUST) genau derselbe sein wie der Wert des Aussteller-Identifikators des Autorisierungsservers, in den die bekannte URI-Zeichenfolge eingefügt wurde, um die URL zu erstellen, die zum Abrufen der Metadaten verwendet wurde. Wenn diese Werte nicht genau identisch sind, dürfen (MUST NOT) die in der Antwort enthaltenen Daten nicht verwendet werden.

Letztes Update am