Oracle Cloud Infrastructure - Dokumentation

Berechtigungstyp "Autorisierungscode"

Verwenden Sie diesen Berechtigungstyp, wenn Sie einen Autorisierungscode abrufen möchten, indem Sie einen Autorisierungsserver als Zwischenstelle zwischen der Clientanwendung und dem Ressourceneigentümer mit Identitätsdomains verwenden.

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

Ein Diagramm, das den Ablauf des Berechtigungscodetyps veranschaulicht.
In diesem OAuth-Fluss:

  1. Ein Benutzer klickt auf einen Link in einer Webserver-Clientanwendung, um Zugriff auf geschützte Ressourcen anzufordern.

  2. Die Clientanwendung leitet den Browser mit einer Anforderung nach einem Autorisierungscode an den Autorisierungsendpunkt oauth2/v1/authorize um.

  3. Der Autorisierungsserver gibt einen Autorisierungscode über eine Browserumleitung an die Clientanwendung zurück, nachdem der Ressourceneigentümer seine Zustimmung gegeben hat.

  4. Die Clientanwendung tauscht den Autorisierungscode dann 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 abzurufen.
    Hinweis

    Zugangsdaten des Ressourceneigentümers werden nie für den Client bereitgestellt.
Funktion Verfügbar
Clientauthentifizierung erforderlich Nein
Client muss Benutzerzugangsdaten kennen Nein
Browserbasierte Endbenutzerinteraktion Ja
Kann externen Identitätsprovider zur Authentifizierung verwenden Ja
Tokenaktualisierung ist zulässig Ja
Zugriffstoken befindet sich im Kontext des Endbenutzers Ja

Siehe ein Beispiel Authorization Code Grant Type Authorization Flow Example.

Autorisierungsablaufbeispiel für Autorisierungscodeerteilungstyp

Dieses Beispiel für einen Autorisierungsablauf führt Sie durch eine OpenID Connect-Anmeldeanforderung mit einem Autorisierungscode.

Dieser Ablauf ist ein dreiteiliger OAuth-Ablauf, der sich auf Szenarios bezieht, in denen die Anwendung die Identitätsdomain-APIs im Namen von Endbenutzern aufruft und in denen manchmal eine Benutzereinwilligung erforderlich ist. Dieser Ablauf zeigt, wie Sie das föderierte Single Sign-On zwischen einer Identitätsdomain und einer benutzerdefinierten Anwendung mit OAuth 2.0 und OpenID Connect konfigurieren.

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

  • Geben Sie Vertrauenswürdige Anwendung als Anwendungstyp an.

  • Wählen Sie Autorisierungscode als Berechtigungstyp aus.

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

  • Wählen Sie optional den Berechtigungstyp Aktualisierungstoken aus, um ein Aktualisierungstoken mit dem Zugriffstoken zurückzugeben.

Weitere Informationen zum Berechtigungstyp "Autorisierungscode" und einem Diagramm zum Autorisierungsablauf finden Sie unter Berechtigungstyp für Autorisierungscode.

Autorisierungsablauf

  1. Ein Benutzer klickt auf einen Link in der Webserver-Clientanwendung (Kundenangebote), um Zugriff auf geschützte Ressourcen anzufordern.

  2. Die App "Customer Quotes" leitet den Browser mit einer Anforderung nach einem Autorisierungscode an den Autorisierungsendpunkt der Identitätsdomain (oauth2/v1/authorize) um.

    Die Anforderungs-URL enthält Abfrageparameter, die den angeforderten Zugriffstyp angeben.
    Hinweis

    Ein Nonce-Wert ist eine kryptografisch starke Zufallszeichenfolge, mit der Sie verhindern können, dass abgefangene Antworten wiederverwendet werden.

    Beispielanforderung: Vertraulicher/Vertrauenswürdiger Client

    GET https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234

    Beispielanforderung: Vertraulicher/Vertrauenswürdiger Client mit Aktualisierungstoken in Anforderung

    GET https://<domainURL>/oauth2/v1/authorize?client_id=<client-id&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid%20<Resource
Server Scope>%20offline_access&nonce=<nonce-value>&state=1234

    Beispielanforderung: Öffentlicher Client

    GET https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=id_token&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234

    Beispielanforderung mit PKCE

    GET https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234&code_challenge=<code-challenge>&code_challenge_method=<plain|S256>'

  3. Die Identitätsdomain empfängt die Anforderung und identifiziert, dass die Customer Quotes-App (identifiziert durch client_id) einen Autorisierungscode anfordert, um weitere Informationen zum Ressourceneigentümer abzurufen (Geltungsbereich openid).)

  4. Wenn der Benutzer noch nicht angemeldet ist, fordert IAM den Benutzer zur Authentifizierung auf. IAM prüft die Zugangsdaten des Benutzers.

  5. Wenn die Anmeldung erfolgreich war, leitet IAM den Browser mit einem Autorisierungscode zur Anwendung "Customer Quotes" um.
    Hinweis

    Wenn sich der Benutzer nicht authentifiziert, wird anstelle des Autorisierungscodes ein Fehler zurückgegeben.

  6. Die Anwendung "Customer Quotes" extrahiert den Autorisierungscode und sendet eine Anforderung an eine Identitätsdomain, um den Autorisierungscode für ein Zugriffstoken auszutauschen.

    Anforderungsbeispiel: Vertraulicher/Vertrauenswürdiger Client

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

    Anforderungsbeispiel: Öffentlicher Client

       curl -i 
   -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' 
   --request POST https://<domainURL>/oauth2/v1/token 
   -d 'grant_type=authorization_code&code=<authz-code>&redirect_uri=<client-redirect-uri>&client_id=<client-id>'

    Beispielanforderung mit PKCE

       curl -i
   -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
   --request POST https://<domainURL>/oauth2/v1/token 
   -d 'grant_type=authorization_code&code=<authz-cod>e&redirect_uri=<client-redirect-uri>&client_id=<client-id>&code_verifier=<code-verifier>'

  7. IAM validiert die Berechtigung und die Benutzerdaten, die mit dem Code verknüpft sind (client_id, client_secret und den Autorisierungscode).

  8. Ein Zugriffstoken und ein Identitätstoken werden zurückgegeben. Das Zugriffstoken enthält Informationen darüber, welche Geltungsbereiche die Anwendung "Kundenangebote" im Namen des Benutzers anfordern kann. Die Anwendung kann dieses Token verwenden, wenn sie APIs im Namen des Benutzers anfordert.

    Das Identitätstoken wird nur abgerufen, wenn Sie den Geltungsbereich openid anfordern. Dieses Token enthält Identifikationsinformationen zum Benutzer und wird für die föderierte Authentifizierung verwendet.

  9. Die Anwendung "Kundenangebote" verarbeitet die id_token und extrahiert dann die von IAM zurückgegebenen Benutzerinformationen.

  10. "Kundenangebote" zeigt die Homepage an, die Informationen zum Benutzer enthält.