Berechtigungstyp "Autorisierungscode"

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

Dieser Ablauf ist ein dreibeiniger 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 Benutzerzustimmung 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 Autorisierungsflussdiagramm finden Sie unter Berechtigungstyp "Autorisierungscode".

Autorisierungsablauf

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

2. Die App "Kundenangebote" leitet den Browser mit einer Anforderung für einen 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 zufällige Zeichenfolge, die Sie verwenden, um zu verhindern, 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 gibt an, dass die App für Kundenangebote (identifiziert durch ihre 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 an die Anwendung "Kundenangebote" um.

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

6. Die Anwendung "Kundenangebote" extrahiert den Autorisierungscode und fordert eine Identitätsdomain auf, den Autorisierungscode gegen 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>'

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

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

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 APIs im Namen des Benutzers angefordert werden.

   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 mit Informationen zum Benutzer an.