Seite 3: Erweitertes Login

Inhaltsverzeichnis

Login mit weiteren Benutzerdaten

In vielen Fällen möchten Clients über die (technische) Benutzer-ID hinaus weitere Attribute der Benutzer abfragen, zum Beispiel den Namen oder die E-Mail-Adresse. Hierfür führt OpenID Connect mit dem UserInfo-Endpunkt eine neue Schnittstelle am OP ein. Unter Nutzung dieses Endpunkts kann ein Client die beim OP verfügbaren Attribute zu einem Benutzer, ebenfalls "Claims" genannt, abfragen.

Die Zugriffe auf den UserInfo-Endpunkt werden durch gewöhnliche OAuth Access Token geschützt. Der Client kann daher alle verfügbaren OAuth-Abläufe verwenden, um ein entsprechend autorisiertes Access Token zu erlangen. Im einfachsten Fall erweitert der Client den Scope-Wert des OpenID-Connect-Authentifizierungs-Requests um vordefinierte Werte, die den Zugriff auf bestimmte Claims anfordern. OpenID Connect definiert die in der folgenden Tabelle dargestellten Standardwerte:

Scope-Wert	Claims
profile	name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at
email	email, email_verified
address	formatted, street_address, locality, region, postal_code, country
phone	phone_number, phone_number_verified

Diese Vorgehensweise soll nun das Beispiel illustrieren. Die Annahme ist, dass der Mediendienst sowohl den Namen als auch die E-Mail-Adresse jedes Benutzers abfragen möchte. Hierzu erweitert dieser den Authentifizierungs-Request um die Scope-Werte "profile" und "email" wie folgt:

HTTP/1.1 302 Found
Location: https://accounts.funcorp.com/oauth/auth?
  response_type=code
  &scope=openid%20profile%20email
  &client_id=SDFGHJKLUZTREDFGHJ
  &state=34790876543456789765
  &redirect_uri=https%3A%2F%2Fmediaservice.funcorp.com%2Flogin_cb

Der Rest des Ablaufs bleibt unverändert. Wenn der Authentifizierungsablauf erfolgreich abgeschlossen ist,

HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
Pragma: no-cache
{
 "access_token": "4vfKjkM8FcGvnzZUN4_KSP0aAp",
 "token_type": "Bearer",
 "expires_in": 3600,
 "id_token": "eyJhb...cifQ.ew...fQ.gg...zqg"
}

dann ist der Mediendienst im Besitz eines Access Token, das diesen zum Zugriff auf die gewünschten Daten berechtigt. Die Abfrage am UserInfo-Endpunkt sieht dann wie folgt aus:

GET /userinfo HTTP/1.1
  Host: accounts.funcorp.com
  Authorization: Bearer 4vfKjkM8FcGvnzZUN4_KSP0aAp

Hierbei wird das Access Token unter Nutzung des mit OAuth 2.0 eingeführten HTTP-Authentifizierungsschemas Bearer an den Server geschickt. Wenn dieses Token gültig ist, werden alle hierdurch autorisierten Benutzerdaten an den Aufrufer geliefert.

HTTP/1.1 200 OK
Content-Type: application/json

{
 "sub": "786767677",
 "name": "Max Mustermann",
 "given_name": "Max",
 "family_name": "Mustermann",
 "email": "m.mustermann@funcorp.com",
 "email_verified": true
}

Wie im Beispiel zu sehen ist, liefert der UserInfo-Endpunkt auch die aus dem ID Token bekannte Benutzer-ID an den Client aus. Der Client muss immer prüfen, dass beide Werte übereinstimmen. Sollte das nicht der Fall sein, dann könnte ein Substitutionsangriff vorliegen. Daher dürfen die Benutzerdaten in einem solchen Fall nicht verwendet werden.

Mit den bisher vorgestellten Funktionen sind die grundsätzlichen Anforderungen für das Login auf einfache Art und Weise abgedeckt. Aber auch wenn die Anwendungsfälle komplizierter werden, hat OpenID Connect eine Menge zu bieten. Einige dieser Anwendungsfälle bespricht der Folgeartikel.