Berechtigungstyp "Clientzugangsdaten"

Verwenden Sie diesen Berechtigungstyp, wenn der Autorisierungsgeltungsbereich auf die geschützten Ressourcen unter der Kontrolle des Clients oder auf geschützte Ressourcen beschränkt ist, die beim OAuth-Autorisierungsserver registriert sind.

Das folgende Diagramm zeigt den Ablauf "Berechtigungstyp für Clientzugangsdaten".

Ein Diagramm, das den Ablauf "Berechtigungstyp für Clientzugangsdaten" veranschaulicht.

In diesem OAuth-Fluss:

  1. Ein vom Client initiiertes Ereignis (z.B. ein geplantes Hintergrundupdate für eine App auf Ihrem Mobilgerät) fordert Zugriff auf eine geschützte Ressource von einer OAuth-Clientanwendung an.

  2. Die Clientanwendung präsentiert ihre eigenen Zugangsdaten, um ein Zugriffstoken und häufig ein Aktualisierungstoken abzurufen. Dieses Zugriffstoken ist entweder mit den eigenen Ressourcen des Clients, aber nicht mit einem bestimmten Ressourceneigentümer, oder mit einem Ressourceneigentümer verknüpft, für den die Clientanwendung anderweitig berechtigt ist, Aktionen auszuführen.

  3. Der Autorisierungsserver gibt das Zugriffstoken an die Clientanwendung zurück.

  4. Die Clientanwendung verwendet das Zugriffstoken in einem API-Aufruf, um die App auf Ihrem Gerät zu aktualisieren.

Funktion Verfügbar
Clientauthentifizierung erforderlich Ja
Client muss Benutzerzugangsdaten kennen Nein
Browserbasierte Endbenutzerinteraktion Nein
Kann externen Identitätsprovider zur Authentifizierung verwenden Nein
Tokenaktualisierung ist zulässig Nein
Zugriffstoken befindet sich im Kontext der Clientanwendung Ja

Einen Beispielablauf finden Sie unter Beispiel für den Berechtigungserteilungstyp "Autorisierungsablauf" für Clientzugangsdaten.

Beispiel für den Berechtigungsablauf "Berechtigungstyp für Clientzugangsdaten"

Der Berechtigungstyp "Clientzugangsdaten" stellt einen bestimmten Berechtigungsablauf bereit, an dem der Ressourceneigentümer nicht beteiligt ist. In diesem Szenariobeispiel führt die Clientanwendung Prozesse aus, die keine Beteiligung des Ressourceneigentümers haben, z.B. einen Batchprozess oder eine Server-zu-Server-Aufgabe.

Wenn Sie diese Berechtigung verwenden, fordert die Clientanwendung ein Zugriffstoken mit eigenen Zugangsdaten (ID und Secret) oder eine Assertion an und verwendet das Zugriffstoken im Namen der Clientanwendung selbst. Dieser Berechtigungsfluss eignet sich am besten, wenn ein Serviceprovider einige API-Methoden bereitstellen möchte, die von der Clientanwendung im Allgemeinen anstelle von Methoden verwendet werden sollen, die für einen bestimmten Ressourceneigentümer gelten. Beispiel: API-Methoden für die Wartung.

Wenn Sie eine Anwendung mit dem Berechtigungstyp "Clientzugangsdaten" in der Identitätsdomainkonsole erstellen:

  • Geben Sie Vertrauenswürdige Anwendung als Anwendungstyp an, da eine App/Browser-Anwendung kein Client Secret hat und die Berechtigung "Clientzugangsdaten" nicht verwenden kann.

  • Wählen Sie als Berechtigungstyp Clientzugangsdaten aus.

Weitere Informationen zum Berechtigungstyp "Clientzugangsdaten" und einem Autorisierungsablaufdiagramm finden Sie unter Berechtigungstyp "Clientzugangsdaten".

Autorisierungsablauf

  1. Ein vom Client initiiertes Ereignis (z.B. eine geplante Aufgabe) fordert Zugriff auf geschützte Ressourcen von einer OAuth-Clientanwendung an.

    Die Ereignis-URL enthält Abfrageparameter, die den angeforderten Zugriffstyp angeben:

    Beispielanforderung mit dem Autorisierungsheader

       curl -i
       -H 'Authorization: Basic <base64Encoded clientid:secret>'
       -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
       --request POST https://<domainURL>/oauth2/v1/token 
       -d 'grant_type=client_credentials&scope=<scope value>'

    Beispielanforderung mit einer JWT-Client-Assertion

       curl -i
       -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
       --request POST https://<domainURL>/oauth2/v1/token 
       -d 'grant_type=client_credentials&client_id=<client-id>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<client-assertion>&scope=<scope value>'
  2. Die Clientanwendung fordert ein Zugriffstoken vom Autorisierungsserver OAuth an.
  3. Der Autorisierungsserver OAuth authentifiziert die Clientanwendung basierend auf dem Autorisierungsheader oder der gesendeten Assertion und gibt ein Zugriffstoken zurück, das alle anwendbaren Geltungsbereiche enthält, basierend auf den Berechtigungen, die durch die Anwendungsrollen dargestellt werden, die der anfordernden Clientanwendung erteilt wurden.
  4. Die Clientanwendung verwendet das Zugriffstoken, um eine Anforderung auszuführen.