2. Client-Registrierung (Client Registration)
Bevor das Protokoll gestartet wird, registriert sich der Client beim Autorisierungsserver (Authorization Server). Die Art und Weise, wie sich der Client beim Autorisierungsserver registriert, liegt außerhalb des Umfangs dieser Spezifikation, umfasst jedoch typischerweise die Interaktion des Endbenutzers mit einem HTML-Registrierungsformular.
Die Client-Registrierung erfordert keine (MUST NOT) direkte Interaktion zwischen dem Client und dem Autorisierungsserver. Wenn sie vom Autorisierungsserver unterstützt wird, kann die Registrierung auf andere Mittel angewiesen sein, um eine Vertrauensbeziehung herzustellen und die Eigenschaften des Clients zu erhalten (wie Weiterleitungs-URI, Client-Typ). Beispielsweise kann die Registrierung mithilfe von selbst ausgestellten oder von Drittanbietern ausgestellten Behauptungen abgeschlossen werden, oder indem der Autorisierungsserver eine Client-Erkennung über einen vertrauenswürdigen Kanal durchführt.
Bei der Registrierung eines Clients sollte (SHOULD) der Client-Entwickler:
- Den Client-Typ wie in Abschnitt 2.1 beschrieben angeben
- Die Weiterleitungs-URI wie in Abschnitt 3.1.2 beschrieben bereitstellen
- Alle anderen vom Autorisierungsserver geforderten Informationen einschließen (z. B. Anwendungsname, Website, Beschreibung, Logo-Bild, Akzeptanz rechtlicher Bedingungen)
2.1. Client-Typen (Client Types)
Basierend auf der Fähigkeit des Clients, sich sicher beim Autorisierungsserver zu authentifizieren (d. h. die Fähigkeit, die Vertraulichkeit seiner Anmeldeinformationen aufrechtzuerhalten), definiert OAuth zwei Client-Typen:
Vertraulicher Client (Confidential Client)
Ein Client, der in der Lage ist, die Vertraulichkeit seiner Anmeldeinformationen aufrechtzuerhalten (z. B. wird der Client auf einem sicheren Server mit eingeschränktem Zugriff auf die Client-Anmeldeinformationen ausgeführt) oder in der Lage ist, die sichere Client-Authentifizierung durch andere Mittel sicherzustellen.
Öffentlicher Client (Public Client)
Ein Client, der nicht in der Lage ist, die Vertraulichkeit seiner Anmeldeinformationen aufrechtzuerhalten (z. B. wird der Client auf dem vom Ressourcenbesitzer verwendeten Gerät ausgeführt, wie eine installierte native Anwendung oder eine webbrowserbasierte Anwendung), und nicht in der Lage ist, die sichere Client-Authentifizierung durch andere Mittel sicherzustellen.
Die Wahl des Client-Typs basiert auf den Sicherheitsauthentifizierungsdefinitionen des Autorisierungsservers und dessen akzeptablem Expositionsniveau der Client-Anmeldeinformationen. Der Autorisierungsserver sollte (SHOULD NOT) Annahmen über den Client-Typ treffen.
Ein Client kann als Satz verteilter Komponenten implementiert werden, von denen jede einen anderen Client-Typ und Sicherheitskontext hat (z. B. ein verteilter Client mit sowohl einer vertraulichen serverbasierten Komponente als auch einer öffentlichen browserbasierten Komponente). Wenn der Autorisierungsserver solche Clients nicht unterstützt oder keine Anleitung bezüglich ihrer Registrierung bereitstellt, sollte (SHOULD) der Client jede Komponente als separaten Client registrieren.
Diese Spezifikation wurde um die folgenden Client-Profile herum entworfen:
Webanwendung (Web Application)
Eine Webanwendung ist ein vertraulicher Client, der auf einem Webserver ausgeführt wird. Der Ressourcenbesitzer greift auf den Client über eine HTML-Benutzeroberfläche zu, die in einem Benutzeragenten auf dem vom Ressourcenbesitzer verwendeten Gerät gerendert wird. Die Client-Anmeldeinformationen sowie alle an den Client ausgegebenen Zugangstokens werden auf dem Webserver gespeichert und sind dem Ressourcenbesitzer nicht ausgesetzt oder zugänglich.
Benutzeragenten-basierte Anwendung (User-Agent-Based Application)
Eine benutzeragenten-basierte Anwendung ist ein öffentlicher Client, bei dem der Client-Code von einem Webserver heruntergeladen und in einem Benutzeragenten (z. B. einem Webbrowser) auf dem vom Ressourcenbesitzer verwendeten Gerät ausgeführt wird. Protokolldaten und Anmeldeinformationen sind für den Ressourcenbesitzer leicht zugänglich (und oft sichtbar). Da diese Anwendungen im Benutzeragenten residieren, können sie bei der Anforderung von Autorisierung nahtlos die Funktionen des Benutzeragenten nutzen.
Native Anwendung (Native Application)
Eine native Anwendung ist ein öffentlicher Client, der auf dem vom Ressourcenbesitzer verwendeten Gerät installiert und ausgeführt wird. Protokolldaten und Anmeldeinformationen sind für den Ressourcenbesitzer zugänglich. Es wird angenommen, dass alle in der Anwendung enthaltenen Client-Authentifizierungsanmeldeinformationen extrahiert werden können. Andererseits können dynamisch ausgegebene Anmeldeinformationen wie Zugangstokens oder Aktualisierungstokens (Refresh Token) ein akzeptables Schutzniveau erreichen. Mindestens sind diese Anmeldeinformationen vor böswilligen Servern geschützt, mit denen die Anwendung interagieren kann. Auf einigen Plattformen können diese Anmeldeinformationen vor anderen Anwendungen geschützt werden, die sich auf demselben Gerät befinden.
2.2. Client-Kennung (Client Identifier)
Der Autorisierungsserver stellt einem registrierten Client eine Client-Kennung (Client Identifier) aus – eine eindeutige Zeichenfolge, die die vom Client bereitgestellten Registrierungsinformationen darstellt. Die Client-Kennung ist kein Geheimnis; sie wird dem Ressourcenbesitzer offengelegt und darf (MUST NOT) allein zur Client-Authentifizierung verwendet werden. Die Client-Kennung ist für den Autorisierungsserver eindeutig.
Die Größe der Client-Kennungszeichenfolge ist in dieser Spezifikation nicht definiert. Der Client sollte (SHOULD) vermeiden, Annahmen über die Größe der Kennung zu treffen. Der Autorisierungsserver sollte (SHOULD) die Größe aller von ihm ausgegebenen Kennungen dokumentieren.
2.3. Client-Authentifizierung (Client Authentication)
Wenn der Client-Typ vertraulich ist, stellen der Client und der Autorisierungsserver eine Client-Authentifizierungsmethode her, die den Sicherheitsanforderungen des Autorisierungsservers entspricht. Der Autorisierungsserver kann (MAY) jede Form der Client-Authentifizierung akzeptieren, die seinen Sicherheitsanforderungen entspricht.
Vertrauliche Clients erhalten in der Regel (oder stellen her) einen Satz von Client-Anmeldeinformationen zur Verwendung bei der Authentifizierung beim Autorisierungsserver (z. B. Passwort, öffentliches/privates Schlüsselpaar). Der Autorisierungsserver kann (MAY) eine Client-Authentifizierungsmethode mit öffentlichen Clients herstellen. Der Autorisierungsserver darf (MUST NOT) sich jedoch nicht auf die öffentliche Client-Authentifizierung verlassen, um den Client zu identifizieren.
Der Client darf (MUST NOT) mehr als eine Authentifizierungsmethode in jeder Anfrage verwenden.
2.3.1. Client-Passwort (Client Password)
Clients mit einem Client-Passwort können (MAY) das in <RFC2617> definierte HTTP-Basic-Authentifizierungsschema verwenden, um sich beim Autorisierungsserver zu authentifizieren. Die Client-Kennung wird mit dem in Anhang B definierten application/x-www-form-urlencoded-Codierungsalgorithmus codiert, und der codierte Wert wird als Benutzername verwendet; das Client-Passwort wird mit demselben Algorithmus codiert und als Passwort verwendet. Der Autorisierungsserver muss (MUST) das HTTP-Basic-Authentifizierungsschema zur Authentifizierung von Clients mit ausgegebenem Client-Passwort unterstützen.
Zum Beispiel (zusätzliche Zeilenumbrüche nur zur Anzeige):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
Alternativ kann (MAY) der Autorisierungsserver die Einbeziehung der Client-Anmeldeinformationen in den Anfragekörper unter Verwendung der folgenden Parameter unterstützen:
client_id
Erforderlich (REQUIRED). Die Client-Kennung, die dem Client während des in Abschnitt 2.2 beschriebenen Registrierungsprozesses ausgestellt wurde.
client_secret
Erforderlich (REQUIRED). Das Client-Geheimnis. Der Client kann (MAY) diesen Parameter weglassen, wenn das Client-Geheimnis eine leere Zeichenfolge ist.
Die Einbeziehung der Client-Anmeldeinformationen in den Anfragekörper unter Verwendung dieser beiden Parameter wird nicht empfohlen (NOT RECOMMENDED) und sollte (SHOULD) auf Clients beschränkt werden, die das HTTP-Basic-Authentifizierungsschema (oder ein anderes passwortbasiertes HTTP-Authentifizierungsschema) nicht direkt verwenden können. Die Parameter dürfen nur im Anfragekörper gesendet werden und dürfen (MUST NOT) in der Anfrage-URI enthalten sein.
Der Autorisierungsserver muss (MUST) die Verwendung von TLS wie in Abschnitt 1.6 beschrieben erfordern, wenn Anfragen mit Passwortauthentifizierung gesendet werden.
Da diese Client-Authentifizierungsmethode ein Passwort enthält, muss (MUST) der Autorisierungsserver alle Endpunkte, die dieses Passwort verwenden, vor Brute-Force-Angriffen schützen.
2.3.2. Andere Authentifizierungsmethoden (Other Authentication Methods)
Der Autorisierungsserver kann (MAY) jedes geeignete HTTP-Authentifizierungsschema unterstützen, das seinen Sicherheitsanforderungen entspricht. Bei Verwendung anderer Authentifizierungsmethoden muss (MUST) der Autorisierungsserver eine Zuordnung zwischen der Client-Kennung (der Registrierung) und dem Authentifizierungsschema definieren.
2.4. Nicht registrierte Clients (Unregistered Clients)
Diese Spezifikation sieht die Verwendung nicht registrierter Clients nicht vor. Der Autorisierungsserver kann (MAY) solche Clients jedoch unterstützen.
Bei Verwendung nicht registrierter Clients wird die Client-Kennung auf eine andere, nicht durch diese Spezifikation definierte Weise erhalten. Der Autorisierungsserver sollte (SHOULD) die Anforderungen und Einschränkungen hinsichtlich der Verwendung nicht registrierter Clients dokumentieren.