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

Verwenden Sie diesen Berechtigungstyp, wenn der Ressourceneigentümer eine Vertrauensbeziehung zum Client hat, z.B. ein Computer-BS oder eine Anwendung mit hohen Berechtigungen, 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 Kennwort von Ressourceneigentümern" veranschaulicht.

In diesem OAuth-Fluss:

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

  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 über den Autorisierungsserver gegen ein Zugriffstoken und häufig ein Aktualisierungstoken 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 wie eine Benutzerliste abzurufen.

Funktion Verfügbar
Clientauthentifizierung erforderlich Nein
Erfordert, dass der Client die Benutzerzugangsdaten kennt Ja
Browserbasierte Endbenutzerinteraktion Nein
Kann externen Identitätsprovider zur Authentifizierung verwenden Nein
Tokenaktualisierung ist zulässig Ja
Zugriffstoken befindet sich im Kontext des Endbenutzers Ja

Siehe ein Beispiel Beispiel für den Berechtigungserteilungstyp "Kennwortzugangsdaten für Ressourceneigentümer".

Beispiel für den Autorisierungsablauf für den Berechtigungstyp "Zugangsdaten für Kennwort von Ressourcenverantwortlichem"

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 Ressourceneigentümer als Berechtigungstyp aus.

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

Weitere Informationen zum Berechtigungstyp "Zugangsdaten für Kennwort des Ressourceneigentümers" und zu einem Autorisierungsablaufdiagramm finden Sie unter Berechtigungstyp für Kennwort von Ressourceneigentümer.

Autorisierungsablauf

  1. Ein Benutzer klickt auf einen Link in der Webserver-Clientanwendung und fordert den 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 dem Autorisierungsheader, der das Aktualisierungstoken in die Anforderung einschließt

       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 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=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, die Aktualisierungstoken in die Anforderung einschließt

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

    Hinweis

    Wenn eine Anforderung für einen ungültigen Geltungsbereich gestellt 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.