OpenID Connect zum Erweitern von OAuth 2.0 verwenden

Ein Identity Token ist ein integritätsgesichertes, in sich geschlossenes Token (im JSON Web Token-(JWT-)Format), das im OpenID Connect-Standard definiert ist und Claims zum Endbenutzer enthält. Das Identitätstoken ist die primäre Erweiterung, mit der OpenID Connect OAuth 2.0 aktiviert, 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 über 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 auf interoperable, REST-ähnliche Weise abrufen. Mit OpenID Connect können Clients aller Art, 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 angezeigte Benutzername und das angezeigte Kennwort den von Ihnen verwalteten Daten entsprechen. Wenn Sie eine beanspruchungsbasierte Identität verwenden, müssen Sie diesen Job an einen Identitätsprovider auslagern.

Die Verantwortung verlagert sich von der Überprüfung von Rohdaten auf die Überprüfung, ob der Anforderer Ihren bevorzugten Identitätsprovider durchlaufen und erfolgreich authentifiziert hat. Der Identitätsprovider stellt eine erfolgreiche Authentifizierung dar, indem ein Token ausgegeben wird. Bevor Sie die Informationen verwenden oder sich darauf als Assertion verlassen können, die der Benutzer authentifiziert hat, müssen Sie sie validieren.

OpenID Discovery-Dokument

Das OpenID Connect 1.0-Protokoll ist eine einfache Identitätsschicht über dem OAuth 2.0-Protokoll, für die mehrere Endpunkte zur Authentifizierung von Benutzern und zum Anfordern von Ressourcen erforderlich sind, die Benutzerinformationen, Token und PublicKeys enthalten. Um herauszufinden, welche Endpunkte Sie verwenden müssen, können Sie mit OpenID Connect ein Discovery-Dokument verwenden, das ein JSON-Dokument an einem bekannten Speicherort ist. Dieses Discovery-Dokument enthält Schlüssel/Wert-Paare, die Details zur Konfiguration des OpenID Connect-Providers bereitstellen, einschließlich der URIs der Autorisierungs-, Token-, Benutzerinfo- und Public-Keysendpunkte. Sie können das Discovery-Dokument für den OpenID Connect-Service der IAM-Identitätsdomain 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

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

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

Benutzerprofilansprüche

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

Der Client muss seine Zugangsdaten und ein Zugriffstoken bereitstellen. Das dargestellte Zugriffstoken muss den Geltungsbereich openid enthalten.

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

Beispiel für eine UserInfo-Endpunktanforderung

Nachdem die Clientanwendung einen Benutzer authentifiziert hat und das Zugriffstoken aufweist, kann der Client dann eine Anforderung an den Endpunkt UserInfo senden, um die angeforderten Attribute zu einem 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 die vom UserInfo-Endpunkt zurückgegebenen Werte vertrauen kann (z.B. als Prüfung auf Tokensubstitutionsangriffe), muss der Client prüfen, ob der von der UserInfo-Endpunktanforderung zurückgegebene sub-Claim mit dem Subjekt aus dem ID-Token übereinstimmt.

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

Dadurch erhalten Sie den Vorteil, dass Sie dem Benutzer-Agent (z. B. einem Webbrowser) und möglicherweise anderen bösartigen Anwendungen keinen Zugriff auf den Benutzer-Agent geben. Der Autorisierungsserver kann den Client auch authentifizieren, bevor er den Autorisierungscode gegen ein Zugriffstoken austauscht. Der Autorisierungscodeablauf funktioniert sowohl mit vertraulichen Clients als auch mit öffentlichen Clients.

Vertrauliche Kunden

Öffentliche Kunden

Öffentliche Clients haben keine Zugangsdaten, sondern eine Client-ID. Der Autorisierungscodeablauf umfasst zwei Schritte. Die Anforderungen umfassen eine browserbasierte GET-Anforderung und dann eine Back-Channel-POST-Anforderung zum Abrufen des Zugriffstokens.

1. Autorisierungscode anfordern.

   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 Beispiele für Anfragen und Antworten sind vergleichbar mit den zuvor besprochenen Anfragen und Antworten des vertraulichen Auftraggebers.

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

2. Das Token anfordern.

   Anforderungsbeispiel

   Hinweis
   
   Diese Anforderung unterscheidet sich von der Anforderung des vertraulichen Clients, bei der die Client-ID und das Client Secret im Header der Basisauthentifizierung angegeben sind. Im öffentlichen Clientfluss gibt es keinen Basisauthentifizierungsheader. 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 den Anwendungen bereitgestellt werden, die Zugriff auf den Benutzer-Agent des Benutzers (z. B. einen Webbrowser) haben.

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

ID-Token abrufen

Zugriffstoken abrufen

Impliziten Ablauf werden drei Schritte ausgeführt, 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 Frontkanal und vom Rückkanal erhalten 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 Business-API-Aufrufe auszuführen.

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

ID-Token abrufen

Zugriffstoken abrufen

Im Hybridfluss werden der Autorisierungscode und das Zugriffstoken in vier Schritten abgerufen:

1. Autorisierungscode und Zugriffstoken anfordern.

   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 Back-Channel 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.

Es gibt zwei Möglichkeiten, eine Abmeldung mit OpenID Connect anzufordern: