Berechtigungstyp "Assertion"

Verwenden Sie diesen Berechtigungstyp, wenn Sie eine vorhandene Vertrauensstellung als Assertion ohne einen direkten Benutzergenehmigungsschritt auf dem OAuth-Autorisierungsserver verwenden möchten.

Im folgenden Diagramm wird der Ablauf "Assertion-Berechtigungstyp" angezeigt.

Ein Diagramm, das den Ablauf "Assertion Grant Type" veranschaulicht.

In diesem OAuth-Ablauf:

Ein Benutzer versucht, auf eine Clientanwendung zuzugreifen und eine generierte Benutzer-Assertion zu senden.
Hinweis

Der Prozess, wie die Assertion erworben wird, ist außerhalb des Geltungsbereichs für diese Erklärung.
Die Clientanwendung fordert ein Zugriffstoken und häufig ein Aktualisierungstoken an, indem sie eine Benutzer-Assertion oder eine Benutzer-Assertion eines Drittanbieters und Clientzugangsdaten bereitstellt.
Der Autorisierungsserver gibt das Zugriffstoken an die Clientanwendung zurück.
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	Ja
Erfordert, dass der Client Benutzerzugangsdaten kennt	Nein
Browserbasierte Endbenutzerinteraktion Hinweis: Der Prozess zum Generieren der Assertion kann Benutzerinteraktionen umfassen.	Nein
Kann einen externen Identitätsprovider für die Authentifizierung verwenden	Ja
Aktualisierungstoken ist zulässig	Ja
Zugriffstoken befindet sich im Kontext des Endbenutzers Ein Zugriffstoken befindet sich im Kontext des Subjekts der Assertion. Dabei kann es sich um einen Endbenutzer, einen Service oder den Client selbst handeln.	Vielleicht

Siehe ein Beispiel für den Autorisierungsablauf für Assertion-Berechtigungstyp.

Beispiel für Autorisierungsablauf für Assertion-Berechtigungstyp

In diesem Beispielablauf hat Example.com mehrere Oracle Cloud-Anwendungen PaaS und SaaS abonniert. Example.com-Benutzer möchten auf Oracle Cloud-Eigenschaften zugreifen können, ohne den Autorisierungsprozess selbst durchlaufen zu müssen (delegierte Autorisierung).

Hinweis

Der Befehl in diesem Beispiel verwendet die URL-Struktur https://<domainURL>/resource-path, wobei <domainURL> die Identity Service-URL und der Ressourcenpfad die Identity Service-API darstellt. Die entsprechende URL-Struktur finden Sie unter Anforderungen senden.

Wenn Sie eine Anwendung mit dem Assertion-Berechtigungstyp in der Identitätsdomainkonsole erstellen:

Geben Sie Mobilanwendung als Anwendungstyp an.
Wählen Sie Assertion als Berechtigungstyp aus.

Weitere Informationen zum Assertion-Berechtigungstyp und einem Autorisierungsflussdiagramm finden Sie unter Assertion-Berechtigungstyp.

Autorisierungsablauf

Ein Benutzer versucht, auf eine Clientanwendung (wie JCS) zuzugreifen.

Die URL enthält Abfrageparameter, die den angeforderten Zugriffstyp angeben. Die SAML2-Assertion ist Base64-codiert, und der Empfängerwert in der SAML-Assertion muss einer der folgenden Werte sein:

Der Aussteller im Feld "Aussteller" der OAuth-Einstellungen in der Benutzeroberfläche.
Oder https://<domainURL>/.
Oder der Wert von secure_saml_sp_sso_endpoint in der Discovery-Antwort.

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 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 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_'

Ein Oracle Web Services Manager-Agent (client-side) fängt die Clientanwendung ab, die einen REST-API-Aufruf an den Ressourcenserver (Fusion-Anwendungen) ausführt, um ein Zugriffstoken abzurufen.
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.
Der Benutzer kann von einer anderen OPC-Anwendung aus auf eine OPC-Anwendung zugreifen.

Oracle Cloud Infrastructure - Dokumentation

Berechtigungstyp "Assertion"

Beispiel für Autorisierungsablauf für Assertion-Berechtigungstyp