Berechtigungstyp "Zugangsdaten für Kennwort von Ressourceneigentümer"

Verwenden Sie diesen Berechtigungstyp, wenn der Ressourceneigentümer eine Vertrauensbeziehung mit dem Client hat, z.B. ein Computer-BS oder eine Anwendung mit hohem Privileg, da der Client das Kennwort verwerfen muss, nachdem er es zum Abrufen des Zugriffstokens verwendet hat.

Das folgende Diagramm zeigt den Ablauf "Berechtigungstyp für Kennwortzugangsdaten des Ressourceneigentümers".

Ein Diagramm, das den Ablauf "Berechtigungstyp für Kennwortzugangsdaten für Ressourceneigentümer" veranschaulicht.

In diesem OAuth-Ablauf:

  1. Der Benutzer klickt auf einen Link in der Clientanwendung, der den Zugriff auf geschützte Ressourcen anfordert.

  2. Die Clientanwendung fordert den Benutzernamen und das Kennwort des Ressourceneigentümers an.

  3. Der Benutzer meldet sich mit seinem Benutzernamen und Kennwort an.

  4. Die Clientanwendung tauscht diese Zugangsdaten für ein Zugriffstoken und häufig ein Aktualisierungstoken vom Autorisierungsserver aus.

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

  6. Die Clientanwendung verwendet das Zugriffstoken in einem API-Aufruf, um geschützte Daten abzurufen, z.B. eine Liste von Benutzern.

Funktion Verfügbar
Erfordert Clientauthentifizierung Nein
Erfordert, dass der Client Kenntnis von Benutzerzugangsdaten hat Ja
Browserbasierte Endbenutzerinteraktion Nein
Kann einen externen Identitätsprovider für die Authentifizierung verwenden Nein
Aktualisierungstoken ist zulässig Ja
Zugriffstoken befindet sich im Kontext des Endbenutzers Ja

Weitere Informationen finden Sie in einem Beispiel unter Beispiel für Berechtigungserteilungstyp "Autorisierungsablauf" für Ressourceneigentümerkennwortzugangsdaten.

Berechtigungstyp "Berechtigungstyp" "Zugangsdaten für Ressourceneigentümer" - Beispiel

In diesem Beispiel für den Autorisierungsablauf wird beschrieben, wie Sie ein Zugriffstoken mit den Zugangsdaten des Ressourceneigentümers (Benutzers) abrufen.

Wenn Sie eine Anwendung mit dem Berechtigungstyp "Ressourceneigentümer" in der Identitätsdomainkonsole erstellen:

  • Geben Sie Vertrauenswürdige Anwendung als Anwendungstyp an.

  • Wählen Sie als Berechtigungstyp Ressourceneigentümer aus.

  • Geben Sie die Umleitungs-URI an, an die Antworten auf Authentifizierungsanforderungen gesendet werden.

Weitere Informationen zum Berechtigungstyp "Zugangsdaten für Ressourceneigentümerkennwort" und einem Autorisierungsflussdiagramm finden Sie unter Berechtigungstyp "Zugangsdaten für Ressourceneigentümerkennwort".

Autorisierungsablauf

  1. Ein Benutzer klickt auf einen Link in der Webserver-Clientanwendung und fordert Zugriff auf geschützte Ressourcen von einer Webserveranwendung eines Drittanbieters an.

  2. Die Clientanwendung erfasst den Benutzernamen und das Kennwort des Benutzers und fordert ein Zugriffstoken vom Autorisierungsserver (AS) OAuth an.

    Die Anforderungs-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=password&username=<user-name>&password=<example-password>&scope=<scope value>'

    Beispielanforderung mit Autorisierungsheader einschließlich Aktualisierungstoken in der Anforderung

       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=password&username=<user-name>&password=<example-password>&scope=<Resource Server Scope>%20offline_access'

    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=password&username=<user-name>&password=<example-password>&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 einer JWT-Client-Assertion einschließlich Aktualisierungstoken in der Anforderung

       curl -i
       -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
       --request POST https://<domainURL>/oauth2/v1/token -d 'grant_type=password&username=<user-name>&password=<example-password>&client_id=<client-id>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<client-assertion>&scope=<Resource Server Scope>%20offline_access'

    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_'
  3. Der Autorisierungsserver OAuth gibt das Zugriffstoken zurück. Das Zugriffstoken enthält alle anwendbaren Geltungsbereiche basierend auf den Berechtigungen, die durch die Identitätsdomainanwendungsrollen repräsentiert werden, die der anfordernden Clientanwendung erteilt wurden, und dem Benutzer, der durch die Clientanforderung angegeben wird (sofern vorhanden).

    Hinweis

    Wenn eine Anforderung für einen ungültigen Geltungsbereich erstellt wurde, wird anstelle des Zugriffstokens ein Fehler zurückgegeben.
  4. Die anfordernde Site verwendet das Zugriffstoken in einem API-Aufruf, um geschützte Daten abzurufen.