Oracle Cloud Infrastructure - Dokumentation

Berechtigungstyp "Clientzugangsdaten"

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

Das folgende Diagramm zeigt den Ablauf "Clientzugangsdaten-Berechtigungstyp".

Ein Diagramm, das den Ablauf "Clientzugangsdaten: Berechtigungstyp" veranschaulicht.

In diesem OAuth-Ablauf:

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

  2. Die Clientanwendung stellt eigene Zugangsdaten bereit, 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 der Client 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
Erfordert Clientauthentifizierung Ja
Erfordert, dass der Client Benutzerzugangsdaten kennt Nein
Browserbasierte Endbenutzerinteraktion Nein
Kann einen externen Identitätsprovider für die Authentifizierung verwenden Nein
Aktualisierungstoken ist zulässig Nein
Zugriffstoken befindet sich im Kontext der Clientanwendung Ja

Ein Beispielablauf finden Sie unter Beispiel für Berechtigungserteilungstyp "Clientzugangsdaten".

Beispiel für Autorisierungsablauf für Berechtigungstyp für Clientzugangsdaten

Der Berechtigungstyp "Clientzugangsdaten" stellt einen bestimmten Berechtigungsfluss bereit, an dem der Ressourceneigentümer nicht beteiligt ist. In diesem Szenariobeispiel führt die Clientanwendung Prozesse aus, an denen kein Ressourceneigentümer beteiligt ist, z.B. ein Batchprozess oder eine Server-zu-Server-Aufgabe.

Bei Verwendung dieser Berechtigung 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 verwendet werden sollen, anstatt Methoden, die für einen bestimmten Ressourceneigentümer gelten, z.B. 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, weil eine App/Browser-Anwendung kein Client Secret aufweist und die Berechtigung "Clientzugangsdaten" nicht verwenden kann.

  • Wählen Sie Clientzugangsdaten als Berechtigungstyp aus.

Weitere Informationen zum Berechtigungstyp "Clientzugangsdaten" und einem Autorisierungsflussdiagramm finden Sie unter Berechtigungstyp für 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 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>'

    Beispielanforderung mit mTLS

    Informationen zum Abrufen der secureDomainURL finden Sie unter Zugriffsberechtigungstypen.

    curl -v \
--cert cert.crt \
--key key.key \
--cacert ca.crt \
--location '<secureDomainURL>/oauth2/v1/token' \
--header 'Authorization: Basic <base64Encoded clientid:secret>'
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=<client-id>' \
--data-urlencode 'scope=urn:opc:idm:_myscopes_'
  2. Die Clientanwendung fordert ein Zugriffstoken vom Autorisierungsserver OAuth an.
  3. Der OAuth-Autorisierungsserver authentifiziert die Clientanwendung basierend auf dem Autorisierungsheader oder der gesendeten Assertion und gibt ein Zugriffstoken zurück, das alle anwendbaren Geltungsbereiche basierend auf den Berechtigungen enthält, die von den Anwendungsrollen dargestellt werden, die der anfordernden Clientanwendung erteilt wurden.
  4. Die Clientanwendung verwendet das Zugriffstoken, um eine Anforderung auszuführen.