OpenID Connect zum Erweitern von OAuth 2.0 verwenden

Ein Identitätstoken ist ein integritätsgesichertes, eigenständiges Token (im JWT-Format (JSON Web Token)), das im OpenID Connect-Standard definiert ist und Ansprüche über den Endbenutzer enthält. Das Identity Token ist die primäre Erweiterung, die OpenID Connect für OAuth 2.0 vornimmt, um die Authentifizierung in einer Identitätsdomain zu aktivieren.

Das Identity Token JWT besteht aus drei Komponenten: einem Header, einer Payload und der digitalen Signatur. Nach dem JWT-Standard sind diese drei Abschnitte Base64URL codiert und durch Punkte getrennt.

OpenID Connect 1.0 ist eine einfache Identitätsschicht auf dem OAuth 2.0-Protokoll. Damit kann eine IAM-Identitätsdomainclientanwendung (als OAuth 2-Client mit Client-ID und Client Secret registriert) die Identität des Endbenutzers basierend auf der von einem Autorisierungsserver (AS) ausgeführten Authentifizierung prüfen und grundlegende Profilinformationen zum Endbenutzer interoperabel, REST-ähnlich abrufen. Mit OpenID Connect können Clients aller Typen, einschließlich webbasierter, mobiler und JavaScript-Clients, Informationen zu authentifizierten Sessions und Endbenutzern anfordern und empfangen. Weitere Informationen finden Sie unter OpenID Connect.

Warum validieren wir Token? Wenn Ihre Webanwendung die Zugangsdaten direkt prüft, prüft sie, ob der Benutzername und das Kennwort dem von Ihnen verwalteten entsprechen. Wenn Sie eine anspruchsbasierte Identität verwenden, geben Sie diese Stelle an einen Identitätsanbieter aus.

Die Zuständigkeit wechselt von der Prüfung von Raw-Zugangsdaten zur Prüfung, ob der Anforderer Ihren bevorzugten Identitätsprovider durchlaufen und erfolgreich authentifiziert hat. Der Identitätsprovider stellt eine erfolgreiche Authentifizierung durch Ausgabe eines Tokens dar. Bevor Sie die Informationen verwenden oder sich darauf verlassen können, dass der Benutzer authentifiziert hat, müssen Sie sie validieren.

OpenID Discovery-Dokument

Das OpenID Connect 1.0-Protokoll ist ein einfacher Identitätslayer über dem OAuth 2.0-Protokoll, der die Verwendung mehrerer Endpunkte zur Authentifizierung von Benutzern und zum Anfordern von Ressourcen erfordert, die Benutzerinformationen, Token und Public Keys enthalten. Um zu ermitteln, welche Endpunkte Sie verwenden müssen, können Sie mit OpenID Connect ein Discovery-Dokument verwenden, bei dem es sich um ein JSON-Dokument handelt, das an einem bekannten Speicherort gefunden wird. Dieses Discovery-Dokument enthält Schlüssel/Wert-Paare, die Details zur Konfiguration des OpenID Connect-Providers enthalten, einschließlich der URIs der Autorisierungs-, Token-, Benutzerinfo- und PublicKey-Endpunkte. Sie können das Discovery-Dokument für den OpenID Connect-Service der IAM-Identitätsdomain von folgender Website abrufen: https://<domainURL>/.well-known/openid-configuration.

Der OpenID Connect-Endpunkt UserInfo wird von einer Anwendung verwendet, um Profilinformationen zur Identität abzurufen, die authentifiziert wurde. Anwendungen können diesen Endpunkt verwenden, um Profilinformationen, Voreinstellungen und andere benutzerspezifische Informationen abzurufen.

Das OpenID Connect-Profil besteht aus zwei Komponenten:

• Ansprüche, die den Benutzer beschreiben

• UserInfo-Endpunkt, der einen Mechanismus zum Abrufen dieser Claims bereitstellt

  Hinweis
  
  Benutzeransprüche können auch im ID-Token angezeigt werden, um einen Rückruf während der Authentifizierungszeit zu vermeiden.

Benutzerprofilansprüche

Der Endpunkt UserInfo stellt eine Gruppe von Claims basierend auf den OAuth2-Geltungsbereichen bereit, die in der Authentifizierungsanforderung dargestellt werden. OpenID Connect definiert fünf Geltungsbereichswerte, die einer bestimmten Gruppe von Standardansprüchen zugeordnet sind:

Der Client muss seine Zugangsdaten und ein Zugriffstoken anzeigen. Das angezeigte Zugriffstoken muss den Geltungsbereich openid enthalten.

Wenn ein Geltungsbereich ausgelassen wird (Beispiel: der Geltungsbereich email wird nicht verwendet), ist der Anspruch (email) in den zurückgegebenen Ansprüchen nicht vorhanden.

Beispiel für eine UserInfo-Endpunktanforderung

Nachdem die Clientanwendung einen Benutzer authentifiziert hat und das Zugriffstoken hat, kann der Client eine Anforderung an den Endpunkt UserInfo senden, um die angeforderten Attribute für einen Benutzer abzurufen. Das folgende Beispiel zeigt ein Anforderungsbeispiel.

   curl -i
   -H 'Content-Type: application/x-www-form-urlencoded'
   -H 'Authorization: Bearer eyJ4NXQjUzI1....rtApFw'-H 'Accept: */*'
   -H 'Content_Language: en-US'--request GET https://<domainURL>/oauth2/v1/userinfo

Antwortbeispiel

Eine erfolgreiche Antwort gibt eine HTTP 200 OK-Antwort und die Claims des Benutzers im JSON-Format zurück:

{
"birthdate":"",
"email":"user@example.com",
"email_verified":false,
"family_name":"user",
"gender":"",
"given_name":"user",
"appRoles":[],
"name":"alice alice",
"preferred_username":"user@example.com",
"sub":"user@example.com",
"updated_at":1495136783,"website":""
}

Bevor die Clientanwendung den vom Endpunkt UserInfo zurückgegebenen Werten vertrauen kann (z.B. als Prüfung auf Tokensubstitutionsangriff), muss der Client prüfen, ob der von der Endpunktanforderung UserInfo zurückgegebene sub-Claim mit dem Subject aus dem ID-Token übereinstimmt.

Verwenden Sie den Ablauf "Autorisierungscode", wenn Clients vorhanden sind, die ein Client Secret sicher zwischen sich und dem Autorisierungsserver verwalten können. Der Ablauf "Autorisierungscode" gibt einen Autorisierungscode an den Client zurück, der den Code dann direkt gegen ein ID-Token und ein Zugriffstoken austauschen kann.

Dies bietet Ihnen den Vorteil, dass Sie dem Benutzer-Agent (wie einem Webbrowser) und möglicherweise anderen bösartigen Anwendungen keinen Zugriff auf den Benutzer-Agent gewähren. Der Autorisierungsserver kann den Client auch authentifizieren, bevor er den Autorisierungscode für ein Zugriffstoken austauscht. Der Ablauf "Autorisierungscode" funktioniert sowohl mit vertraulichen Clients als auch mit öffentlichen Clients.

Vertrauliche Clients

Öffentliche Clients

Öffentliche Clients verfügen nicht über Zugangsdaten, sondern über eine Client-ID. Der Ablauf "Autorisierungscode" umfasst zwei Schritte. Die Anforderungen umfassen eine browserbasierte GET-Anforderung und dann eine Back-Channel POST-Anforderung zum Abrufen des Zugriffstokens.

1. Fordern Sie den Autorisierungscode an.

   Anforderungsbeispiel

   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

   Antwortbeispiel

   Hinweis
   
   Diese Anforderungs- und Antwortbeispiele ähneln den zuvor besprochenen Anforderungen und Antworten des Vertraulichen Clients.

   https://<domainURL>/?code=AQIDBAXv9lZQ....F9NCA=

2. Fordern Sie das Token an.

   Anforderungsbeispiel

   Hinweis
   
   Diese Anforderung unterscheidet sich von der Confidential Client-Anforderung, bei der die Client-ID und das Client Secret im Basisauthentifizierungsheader angegeben sind. Im öffentlichen Clientablauf ist kein Basisauthentifizierungsheader vorhanden. Die Client-ID wird als Teil der Anforderungs-Payload angegeben.

      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>&reidrect_uri=<client-redirect-uri>&client_id=<client-id>'

   Antwortbeispiel

   {
   "access_token":"eyJ4NXQjUzI1???.xhtnbw",
   "token_type":"Bearer",
   "expires_in":27261,
   "id_token":"eyJ4NXQjUzI1???.._XLqUw"
   }
   

Verwenden Sie den impliziten Ablauf, wenn Sie einen browserbasierten Client mit einer Skriptsprache wie JavaScript implementiert haben. Das Zugriffstoken und das ID-Token werden direkt an den Client zurückgegeben. Dadurch können diese Token dem Benutzer und Anwendungen zugänglich gemacht werden, die Zugriff auf den Benutzer-Agent des Benutzers haben (z. B. einen Webbrowser).

Die folgenden response_type-Werte werden mit dem Implicit-Ablauf unterstützt:

ID-Token abrufen

Zugriffstoken abrufen

Der implizite Ablauf umfasst drei Schritte, um ein Zugriffstoken abzurufen:

1. Fordern Sie das Zugriffstoken an.

   Anforderungsbeispiel

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=token&redirect_uri=<client_redirect_uri>&scope=address+openid+profile

2. Der Benutzer meldet sich an und erteilt seine Zustimmung (basierend auf den angeforderten Geltungsbereichen).

3. Antwort mit Zugriffstoken

   Antwortbeispiel

   Hinweis
   
   Alle Antwortparameter werden der Fragmentkomponente der Umleitungs-URI hinzugefügt.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1...4WGvJQ&token_type=Bearer&expires_in=3600

ID-Token und Zugriffstoken abrufen

Verwenden Sie den Hybridfluss, wenn Sie Token getrennt vom Vorderkanal und dem Hinterkanal abrufen möchten. Beispiel: Sie haben eine Browserkomponente wie JavaScript und eine Backend-Serverkomponente wie Node.js. Die Browserkomponente ruft den Autorisierungscode und das ID-Token ab und kann dann den UI-Inhalt personalisieren. Die Backend-Komponente ruft das Zugriffstoken ab, um Geschäfts-API-Aufrufe auszuführen.

Clients müssen sowohl browserbasierte Anforderungen und Antworten als auch programmgesteuerte/rückkanalige Anforderungen und Antworten unterstützen, um den Hybridfluss zu verwenden. Der Hybrid-Flow funktioniert sowohl mit vertraulichen Kunden als auch mit öffentlichen Kunden. Die folgenden response_type-Werte werden mit dem Hybridfluss unterstützt:

ID-Token abrufen

Zugriffstoken abrufen

Der Hybridablauf umfasst vier Schritte, um den Autorisierungscode und das Zugriffstoken abzurufen:

1. Fordern Sie den Autorisierungscode und das Zugriffstoken an.

   Anforderungsbeispiel

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code token&redirect_uri=<client_redirect_uri>&scope=http://<domainURL>/test

2. Der Benutzer meldet sich an und erteilt seine Zustimmung (basierend auf den angeforderten Geltungsbereichen).

3. Antwort mit ID-Token und Autorisierungscode.

   Antwortbeispiel

   Hinweis
   
   Alle Antwortparameter werden der Fragmentkomponente der Umleitungs-URI hinzugefügt.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1....Pudw9A&code=AQIDBAU6d6Ae....F9NCA=&token_type=Bearer&expires_in=3600

4. Die Clientanwendung verwendet den Autorisierungscode und fordert einen Backkanal an, um ein neues Zugriffstoken abzurufen.

   Anforderungsbeispiel

      curl -i
     -H 'Authorization: Basic YjA3NTZkNDc5M2QwNDZjNjhjZWVmY2UxZjE4ZGUwMWM6NGYzZjJjN2EtZTBjZC00NzcyLWE5MTYtNjI3ZmExNzA2NWE5'
      -H 'Accept: */*''
      --request POST 'https://<domainURL>/oauth2/v1/token' -d 'grant_type=authorization_code&code=AQIDBAU6d6Ae...NCA%3D'

   Antwortbeispiel

   {
   "access_token":"eyJ4NXQjUzI1....Tgs9LA",
   "token_type":"Bearer",
   "expires_in":3600
   }

ID-Token und Zugriffstoken abrufen

Sie können OpenID Connect für browserbasierte Abmeldeanforderungen verwenden.

Sie können eine Abmeldung mit OpenID Connect auf zwei Arten anfordern: