UserInfo-Endpunkt für OpenID Connect aufrufen

Der UserInfo-Endpunkt gibt Ansprüche für einen Benutzer zurück, der mit der OpenID Connect-Authentifizierung authentifiziert wird.

Informationen zu diesem Vorgang

Um die Ansprüche für einen Benutzer zu erhalten, setzt ein Client eine Anforderung an den UserInfo-Endpunkt ab, indem er ein Zugriffstoken als Berechtigungsnachweis verwendet. Das Zugriffstoken muss über die OpenID Connect-Authentifizierung abgerufen werden. Die Ansprüche für den Benutzer, der durch das Zugriffstoken dargestellt wird, werden als JSON-Objekt zurückgegeben, das eine Sammlung von Name/Wert-Paaren für die Ansprüche enthält. Der UserInfo-Endpunkt ist eine mit OAuth 2.0 geschützte Ressource, d. h., dass der für den Zugriff auf den Endpunkt erforderliche Berechtigungsnachweis das Zugriffstoken ist.

Die Ansprüche, die vom UserInfo-Endpunkt zurückgegeben werden, können mit der Konfiguration des OpenID Connect-Providers angepasst werden. Weitere Informationen hierzu enthält der Abschnitt Vom UserInfo-Endpunkt zurückgegebene Ansprüche konfigurieren.

Ein Server mit WebSphere Application Server Traditional mit aktiviertem OpenID Connect hat unter der folgenden URL Zugriff auf den OpenID Connect-UserInfo-Endpunkt:
https://server.example.com:443/oidc/endpoint/<Providername>/userinfo
Fehler vermeiden: Wenn Sie einen Proxy für abgehende Anforderungen verwenden, beachten Sie, dass die OpenID Connect-RP keine Möglichkeit bereitstellt, Anforderungen automatisch über einen Proxy-Host weiterzuleiten.

Wenn Sie einen Proxy für den Zugriff auf OpenID Connect Provider (OP) verwenden müssen, muss der Wert, den Sie für eine beliebige auf OP bezogene URL-Eigenschaft eingeben, den Proxy-Host und Port und nicht den Host und Port des externen OP enthalten.

In den meisten Fällen können Sie den OP-Host und Port durch den Proxy-Host und Port ersetzen. Die URL, die Sie eingeben, muss für die RP und den Client (Browser oder Anwendung) sichtbar sein. Weitere Informationen darüber, wie Sie die richtige zu verwendende URL ermitteln, erhalten Sie von Ihrem Proxy-Administrator.

Der Client in diesem Beispiel erwartet, dass der SSL-Port auf 443 gesetzt ist.

Vorgehensweise

  1. Konfigurieren Sie eine Authentifizierung mit einem über die OpenID Connect-Authentifizierung abgerufenen Zugriffstoken. Das Zugriffstoken kann im HTTP-Basisberechtigungsheader oder mit dem Anforderungsparameter access_token bereitgestellt werden. In beiden Fällen ist es nicht erforderlich, das Zugriffstoken zu codieren.
  2. Senden Sie die GET- oder POST-Anforderung an die UserInfo-Endpunkt-URL.

Ergebnisse

Nachdem Sie diese Schritte ausgeführt haben, haben Sie eine gültige HTTP-Anforderung, die an den UserInfo-Endpunkt gesendet wird, wie im Abschnitt "Beispiele" zu sehen ist.

Bei gültigen Anforderungen gibt der UserInfo-Endpunkt die Antwort HTTP 200 mit einem JSON-Objekt im Format application/json zurück, das die Ansprüche enthält, die für den OpenID Connect-Provider konfiguriert sind.

Beispiel

Die folgenden Beispiele veranschaulichen Anforderungen mit einem gültigen Token und ungültigen Tokens.

  • Anforderung, die den HTTP-Bearer-Berechtigungsheader für die Übergabe des Zugriffstoken verwendet
  • Antwort für ein gültiges Zugriffstoken
  • Ungültige Zugriffstokens
Eine Beispielanforderung, die den HTTP-Bearer-Berechtigungsheader für die Übergabe des Zugriffstokens verwendet:
POST /register HTTP/1.1
Accept: application/x-www-form-urlencoded
Authorization: Bearer fAAdLO1c6QWDbPs9HrWHz5e7nRWVAnxqTTP7i88G
Das Token kann auch mit dem Anforderungsparameteraccess_token übergeben werden:
 POST /register HTTP/1.1
 Accept: application/x-www-form-urlencoded
     access_token=fAAdLO1c6QWDbPs9HrWHz5e7nRWVAnxqTTP7i88G

Es hat sich bewährt, den HTTP-Berechtigungsheader anstelle des Anforderungsparameters access_token zu verwenden, weil HTTP-Anforderungsparameter, die möglicherweise sensible Informationen enthalten, in der Browserhistorie oder im Cache gespeichert werden können.

Unten sehen Sie eine Beispielantwort für ein gültiges Zugriffstoken. Die Ansprüche sub und groupIds werden immer zurückgegeben. Die anderen Ansprüche, die hier gezeigt werden, sind die Standardansprüche für einen OpenID Connect-Provider.
 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
 Pragma: no-cache
{
   "sub"          : "bob",
   "groupIds"     : [ "bobsdepartment","administrators" ], 
   "given_name"   : "Bob",
   "name"         : "Bob Smith",
   "email"        : "bob@mycompany.com",
   "phone_number" : "+1 (604) 555-1234;ext5678",
   "address"      : { "formatted" : "123 Main St., Anytown, TX 77777" },
   "picture"      : "http://mycompany.com/bob_photo.jpg"
}
Für ein ungültiges Zugriffstoken gibt der UserInfo-Endpunkt den Statuscode "HTTP 401" mit einer Fehlernachricht im WWW-AUTHENTICATE-Header zurück.
HTTP/1.1 401 Unauthorized
CONTENT-LENGTH : 0
WWW-AUTHENTICATE : Bearer error=invalid_token,       
   error_description=CWWKS1617E: Es wurde eine userinfo-Anforderung mit einem Zugriffstoken übergeben,
   das nicht erkannt wurde. Die Anforderungs-URI ist
   /oidc/endpoint/MyOAuthProvider/userinfo.

Symbol das den Typ des Artikels anzeigt. Taskartikel

Dateiname: twlp_oidc_userinfo_endpoint.html