Seite 2: Registrierung

Inhaltsverzeichnis

Registrieren beim OP

Bevor der Authentifizierungsprozess starten kann, benötigt News Corp für die weiteren Interaktionen eine gültige OAuth client_id bei Fun Corp. Da sich beide vorher nicht kannten, ist hierfür ein dynamischer Prozess erforderlich, der bei Bedarf durchgeführt wird. Hierfür spezifiziert OpenID Connect die sogenannte dynamische Client-Registrierung. Kern dieser Spezifikation ist ein weiterer Endpunkt für die Registrierung von Clients (registration_endpoint). An ihn sendet der Client jetzt einen Registrierungs-Request.

POST /connect/register HTTP/1.1
 Content-Type: application/json
 Accept: application/json
 Host: accounts.funcorp.com

 {
  "application_type": "web",
  "redirect_uris":
    ["https://portal.newscorp.com/callback"],
  "client_name": "News Corp",
  "token_endpoint_auth_method": "client_secret_basic",
   ...
 }

Im Request kann der Client dem Autorisierungsserver alle notwendigen Metadaten über sich bekannt geben. Unter anderem kann er seinen Anwendungstyp (application_type) und seine Redirect-URIs spezifizieren. Der Server wird beim Verarbeiten von Authentifizierungs-Requests ausschließlich Redirect-URIs akzeptieren, die hier aufgeführt wurden. Als Ergebnis des Registrierungs-Requests legt der Autorisierungsserver einen neuen Client Account an und liefert in der Response, neben einer Menge weiterer Metadaten, die zugehörige client_id und gegebenenfalls das korrespondierende client_secret an den Client aus.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "client_id": "s6BhdRkqt3",
 "client_secret":
 "ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
 "client_secret_expires_at": 1577858400,
  ...
}

Unter Nutzung der neuen client_id kann das Nachrichtenportal jetzt einen Standard-Authentifizierungs-Request an Fun Corp stellen.

HTTP/1.1 302 Found
Location: https://accounts.funcorp.com/oauth/auth?
  response_type=code
  &scope=openid%20profile%20email
  &client_id=s6BhdRkqt3
  &state=3479087654367666666765
  &redirect_uri=https%3A%2F%2Fportal.newscorp.com%2Fcallback

Der gesamte Prozess des Logins und des Zugriffs auf Benutzerdaten entspricht dem im ersten Artikel vorgestellten Abläufen.

Bei der Bereitstellung von Benutzerdaten an Dritte wird jedoch davon ausgegangen, dass der OpenID Provider die Zustimmung des Benutzers vor dem Übertragen der Daten an den Client einholt (der sogenannte "User Consent"). Des Weiteren erlaubt es OpenID Connect, dass der OP für jeden Client und einen bestimmten Benutzer eine andere Benutzer-ID (einen sogenannten "Pairwise Pseudonymous Identifier") ausstellt. Das soll verhindern, dass verschiedene Clients Daten einem bestimmten Benutzer zuordnen können.

Maßgeschneiderte Authentifizierung

In manchen Situationen möchte die Anwendung gezielt darauf Einfluss nehmen, ob der OP mit dem Benutzer im Rahmen des Authentifizierungsprozesses eine Benutzerinteraktion durchführt und welche Methoden er hierzu verwendet. Dazu stellt OpenID Connect einige Stellschrauben bereit: Mit dem Parameter "prompt" kann der Client steuern, ob eine Benutzerinteraktion stattfindet. Stellvertretend sollen hier zwei (komplementäre) Werte erläutert werden.

Wenn der Client möchte, dass eine Benutzerinteraktion auf keinen Fall stattfindet, zum Beispiel bei der Eingabe von Credentials, verwendet er den Wert "none". Kann der OP unter dieser Bedingung den Prozess nicht erfolgreich durchführen, dann wird als Ergebnis des Authentifizierungsablaufs eine aussagekräftige Fehlermeldung, etwa login_required, an den Client zurückgemeldet. Die Option "none" wird gerne verwendet, um Portale (optional) zu personalisieren, wenn sowieso mit hoher Wahrscheinlichkeit eine Login-Sitzung des Benutzers vorliegt. In einem solchen Fall möchte das Portal aber nicht, dass der Prozess blockiert, weil eine Eingabeseite für Benutzername und Passwort angezeigt wird.

An dieser Stelle sei explizit darauf hingewiesen, dass kein Client diese Option verwenden darf, um unautorisiert auf Identitätsdaten eines Benutzers zuzugreifen. Grundsätzlich sollte der OP solche Daten nur an einen Client weitergeben, wenn dieser hierzu autorisiert ist. Das kann durch eine systemseitige Policy oder durch die explizite Freigabe durch den Benutzer erfolgen. Liegt eine solche Autorisierung nicht vor, wird der OP den Request mit einer Fehler-Response consent_required beantworten.

Mit dem Wert "login" signalisiert der Client an den Autorisierungsserver, dass der Benutzer unmittelbar durch (ggf. erneute) Eingabe von Credentials authentifiziert werden soll – ein SSO darf also nicht greifen. Diese Option kommt zum Beispiel zum Einsatz, wenn der Client eine besonders sicherheitskritische Operation durchführen möchte (z. B. Passwortänderung oder einen Bezahlvorgang) und daher sicherstellen will, dass wirklich der legitime Benutzer gerade das Gerät nutzt und keine Übernahme einer laufenden Sitzung durch einen anderen Benutzer erfolgt ist.

Es kann auch sein, dass der Client nur eine erneute Eingabe der Credentials erzwingen möchte, wenn seit der letzten Authentifizierung schon eine bestimmte Zeit vergangen ist. In dem Fall kann er anstelle von "prompt" den Parameter "max_age" verwenden, in dem er (in Sekunden) spezifiziert, wie lange der Zeitpunkt der Authentifizierung höchstens vergangen sein darf.

Möchte der Client ein bestimmtes Sicherheitsniveau bei der Authentifizierung des Benutzers vorgeben, verwendet er den Parameter "acr_values", um die symbolischen Namen von Authentifizierungs-Policies (sog. "Authentication Context Class Reference") anzugeben, denen die Authentifizierung genügen muss. Welche der angeforderten Policies erfüllt wurde, teilt der OP im "acr"-Claim des ID Token mit. Die Spezifikation legt keine konkreten Policies fest, verweist aber auf den ISO-Standard 29115. In ihm wird die Verlässlichkeit eines Authentifizierungsvorgangs in vier Klassen (Levels of Assurance 1-4) aufgeteilt. Ein möglicher Wert könnte also acr_values="iso29115_3" sein.

Aussehen ist alles

Typischerweise sind die Anforderungen an die Qualität der Nutzungserfahrung einer Anwendung hoch. Das Verwenden eines Redirect-basierten Protokolls und eigener HTML-Masken für das Login erschwert dabei einen nahtlosen Fluss durch die Anwendung. Um die Integration dennoch so gut wie möglich implementieren zu können, stellt OpenID Connect durch den Parameter "display" einen Weg bereit, dem OP Hinweise auf die gewünschte Art der Darstellung der Benutzerschnittstelle zu geben. Damit kann der Client dem OP zum Beispiel mitteilen, ob er als volle Browserseite (display=page) oder in einem Pop-up-Fenster (display=popup) dargestellt wird. Diese Information kann der OP verwenden, um seine Darstellung entsprechend anzupassen. Damit erreicht man, dass der verfügbare Raum zielgerichtet verwendet wird beziehungsweise die Eigenschaften der Geräteklasse (display=touch) besonders berücksichtigt werden. Es steht dem OP aber immer frei, die Eigenschaften des User Agent selbstständig zu erkennen und seine Benutzerschnittelle entsprechend zu adaptieren (Responsive Design).

Wünscht der Client die Verwendung einer bestimmten Sprache, die etwa von den Einstellungen des Browsers abweicht, kann er diese mit dem Parameter "ui_locales" anfordern.

Eine perfekte Integration zwischen dem OP und den umgebenden Prozessen erfordert aber noch andere Funktionen. Eine ermöglicht der Parameter "login_hint". Hiermit kann der Client dem OP einen Hinweis geben, mit welcher Benutzer-ID sich der Benutzer einloggen möchte, zum Beispiel einer E-Mail-Adresse oder einem Benutzernamen. Die Verwendung dieses Parameters macht in Situationen Sinn, in denen der Client den Benutzer schon im Vorfeld nach seiner Benutzer-ID gefragt oder diesen anderweitig identifiziert hat. Dann spart sich der Benutzer die erneute Eingabe des Benutzernamens.