1. Einführung

Damit ein OAuth 2.0 [RFC6749] Client einen OAuth 2.0 Autorisierungsserver nutzen kann, benötigt der Client spezifische Informationen, um mit dem Server zu interagieren, einschließlich einer OAuth 2.0 Client-Kennung zur Verwendung auf diesem Server. Diese Spezifikation beschreibt, wie ein OAuth 2.0 Client dynamisch bei einem Autorisierungsserver registriert werden kann, um diese Informationen zu erhalten.

Als Teil des Registrierungsprozesses definiert diese Spezifikation auch einen Mechanismus, mit dem der Client dem Autorisierungsserver einen Satz von Metadaten präsentieren kann, wie z. B. einen Satz gültiger Weiterleitungs-URIs. Diese Metadaten können entweder selbstbestätigt oder als ein Satz von Metadaten, genannt Software-Statement, übermittelt werden, der digital signiert oder mit einem Message Authentication Code (MAC) geschützt ist; im Falle eines Software-Statements bürgt der Aussteller für die Gültigkeit der Daten über den Client.

Traditionell wird die Registrierung eines Clients bei einem Autorisierungsserver manuell durchgeführt. Die in dieser Spezifikation definierten Mechanismen können entweder von einem Client verwendet werden, um sich dynamisch bei Autorisierungsservern zu registrieren, oder von einem Client-Entwickler, um den Client programmgesteuert bei Autorisierungsservern zu registrieren. Mehrere Anwendungen, die OAuth 2.0 verwenden, haben zuvor Mechanismen entwickelt, um solche Registrierungen durchzuführen. Diese Spezifikation verallgemeinert die Registrierungsmechanismen, die von "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] definiert und vom "User Managed Access (UMA) Profile of OAuth 2.0" [UMA-Core] verwendet werden, auf eine Weise, die mit beiden kompatibel ist und gleichzeitig auf einen breiteren Satz von OAuth 2.0-Anwendungsfällen anwendbar ist.

1.1. Notationelle Konventionen

Die Schlüsselwörter 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY' und 'OPTIONAL' in diesem Dokument sind so auszulegen, wie in [RFC2119] beschrieben.

Sofern nicht anders vermerkt, unterscheiden alle Protokollparameternamen und -werte Groß- und Kleinschreibung.

1.2. Terminologie

Diese Spezifikation verwendet die Begriffe "Access Token" (Zugriffstoken), "Authorization Code" (Autorisierungscode), "Authorization Endpoint" (Autorisierungsendpunkt), "Authorization Grant" (Autorisierungserteilung), "Authorization Server" (Autorisierungsserver), "Client", "Client Identifier" (Client-Kennung), "Client Secret" (Client-Geheimnis), "Grant Type" (Gewährungstyp), "Protected Resource" (Geschützte Ressource), "Redirection URI" (Weiterleitungs-URI), "Refresh Token" (Aktualisierungstoken), "Resource Owner" (Ressourceninhaber), "Resource Server" (Ressourcenserver), "Response Type" (Antworttyp) und "Token Endpoint" (Token-Endpunkt), die durch OAuth 2.0 [RFC6749] definiert sind, und verwendet den Begriff "Claim" (Anspruch), der durch JSON Web Token (JWT) [RFC7519] definiert ist.

Diese Spezifikation definiert die folgenden Begriffe:

Client Software Software, die einen OAuth 2.0 Client implementiert.

Client Instance (Client-Instanz) Eine bereitgestellte Instanz einer Client-Software.

Client Developer (Client-Entwickler) Die Person oder Organisation, die ein Client-Softwarepaket erstellt und für die Verteilung vorbereitet. Zum Zeitpunkt der Erstellung des Clients weiß der Entwickler oft nicht, wer die bereitstellenden Dienstanbieter-Organisationen sein werden. Client-Entwickler müssen die dynamische Registrierung verwenden, wenn sie Aspekte der Software, wie z. B. die Bereitstellungs-URLs, zum Zeitpunkt der Kompilierung nicht vorhersagen können. Dies kann beispielsweise auftreten, wenn der Software-API-Herausgeber und die bereitstellende Organisation nicht identisch sind.

Client Registration Endpoint (Client-Registrierungsendpunkt) OAuth 2.0 Endpunkt, über den ein Client bei einem Autorisierungsserver registriert werden kann. Die Mittel, mit denen die URL für diesen Endpunkt erhalten wird, liegen außerhalb des Geltungsbereichs dieser Spezifikation.

Initial Access Token (Initiales Zugriffstoken) OAuth 2.0 Zugriffstoken, das optional von einem Autorisierungsserver an einen Entwickler oder Client ausgegeben wird und zur Autorisierung von Aufrufen an den Client-Registrierungsendpunkt verwendet wird. Typ und Format dieses Tokens sind wahrscheinlich dienste-spezifisch und liegen außerhalb des Geltungsbereichs dieser Spezifikation. Die Mittel, mit denen der Autorisierungsserver dieses Token ausgibt, sowie die Mittel, mit denen der Registrierungsendpunkt dieses Token validiert, liegen außerhalb des Geltungsbereichs dieser Spezifikation. Die Verwendung eines initialen Zugriffstokens ist erforderlich, wenn der Autorisierungsserver die Parteien einschränkt, die einen Client registrieren können.

Deployment Organization (Bereitstellungsorganisation) Eine administrative Sicherheitsdomäne, unter der eine Software-API (Dienst) bereitgestellt und durch ein OAuth 2.0-Framework geschützt wird. In einigen OAuth-Szenarien sind die Bereitstellungsorganisation und der Software-API-Herausgeber identisch. In diesen Fällen hat die bereitstellende Organisation oft eine enge Beziehung zu Client-Softwareentwicklern. In vielen anderen Fällen kann der Definierer des Dienstes ein unabhängiger Drittanbieter oder eine Standardisierungsorganisation sein. Wenn nach einer veröffentlichten Spezifikation für eine API gearbeitet wird, kann der Client-Softwareentwickler keine vorherige Beziehung zu den potenziell vielen Bereitstellungsorganisationen haben, die die Software-API (Dienst) bereitstellen.

Software API Deployment (Software-API-Bereitstellung) Eine bereitgestellte Instanz einer Software-API, die durch OAuth 2.0 (eine geschützte Ressource) in einer bestimmten Bereitstellungsorganisationsdomäne geschützt ist. Für jede bestimmte Software-API kann es eine oder mehrere Bereitstellungen geben. Eine Software-API-Bereitstellung verfügt typischerweise über einen zugehörigen OAuth 2.0 Autorisierungsserver sowie einen Client-Registrierungsendpunkt. Die Mittel, mit denen Endpunkte erhalten werden, liegen außerhalb des Geltungsbereichs dieser Spezifikation.

Software API Publisher (Software-API-Herausgeber) Die Organisation, die eine bestimmte web-zugängliche API definiert, die in einer oder mehreren Bereitstellungsumgebungen bereitgestellt werden kann. Ein Herausgeber kann jedes Standardisierungsgremium, jede kommerzielle, öffentliche, private oder Open-Source-Organisation sein, die für die Veröffentlichung und Verteilung von Software- und API-Spezifikationen verantwortlich ist, die über OAuth 2.0 geschützt werden können. In einigen Fällen können ein Software-API-Herausgeber und ein Client-Entwickler dieselbe Organisation sein. Zum Zeitpunkt der Veröffentlichung einer web-zugänglichen API hat der Software-Herausgeber oft keine vorherige Beziehung zu den bereitstellenden Organisationen.

Software Statement (Software-Statement) Ein digital signiertes oder MAC-geschütztes JSON Web Token (JWT) [RFC7519], das Metadatenwerte über die Client-Software zusichert. In einigen Fällen wird ein Software-Statement direkt vom Client-Entwickler ausgegeben. In anderen Fällen wird ein Software-Statement von einer Drittanbieter-Organisation zur Verwendung durch den Client-Entwickler ausgegeben. In beiden Fällen soll die Vertrauensbeziehung, die der Autorisierungsserver mit dem Aussteller des Software-Statements hat, als Eingabe für die Bewertung verwendet werden, ob die Registrierungsanforderung akzeptiert wird. Ein Software-Statement kann einem Autorisierungsserver als Teil einer Client-Registrierungsanforderung präsentiert werden.

1.3. Protokollablauf

    +--------(A)- Initiales Zugriffstoken (OPTIONAL)
    |
    |   +----(B)- Software-Statement (OPTIONAL)
    |   |
    v   v
+-----------+                                      +---------------+
|           |--(C)- Client-Registrierungsanforderung ->|    Client     |
| Client or |                                      | Registrierungs- |
| Developer |<-(D)- Client-Informationsantwort ----|    Endpunkt     |
|           |        oder Client-Fehlerantwort     +---------------+
+-----------+

Abbildung 1: Abstrakter dynamischer Client-Registrierungsablauf

Der in Abbildung 1 dargestellte abstrakte dynamische OAuth 2.0 Client-Registrierungsablauf beschreibt die Interaktion zwischen dem Client oder Entwickler und dem in dieser Spezifikation definierten Endpunkt. Diese Abbildung zeigt keine Fehlerbedingungen. Dieser Ablauf umfasst die folgenden Schritte:

(A) Optional wird dem Client oder Entwickler ein initiales Zugriffstoken ausgestellt, das Zugriff auf den Client-Registrierungsendpunkt gewährt. Die Methode, mit der das initiale Zugriffstoken an den Client oder Entwickler ausgegeben wird, liegt außerhalb des Geltungsbereichs dieser Spezifikation.

(B) Optional wird dem Client oder Entwickler ein Software-Statement zur Verwendung mit dem Client-Registrierungsendpunkt ausgestellt. Die Methode, mit der das Software-Statement an den Client oder Entwickler ausgegeben wird, liegt außerhalb des Geltungsbereichs dieser Spezifikation.

(C) Der Client oder Entwickler ruft den Client-Registrierungsendpunkt mit den gewünschten Registrierungsmetadaten des Clients auf, wobei optional das initiale Zugriffstoken aus (A) enthalten ist, wenn eines vom Autorisierungsserver benötigt wird.

(D) Der Autorisierungsserver registriert den Client und gibt zurück:

  *  die registrierten Metadaten des Clients,

  *  eine Client-Kennung, die auf dem Server eindeutig ist, und

  *  einen Satz von Client-Anmeldeinformationen wie ein Client-Geheimnis, falls für diesen Client zutreffend.

Beispiele für verschiedene Konfigurationen und Verwendungen sind in Anhang A enthalten.