Konzept

OpendID Connect ist ein Standard zur Authentifizierung an einem HTTP-Endpunkt/Ressourcen-Server (hier Lobster Integration).

Dabei ist die Idee, dass ein HTTP-Endpunkt/Ressourcen-Server nicht mehr selbst die Verwaltung von berechtigten Clients übernehmen muss und beispielsweise Credentials wie Benutzername und Passwort prüft. Stattdessen wird die Authentifizierung von einer dritten Stellen (OpenID-Anbieter/Provider) vorgenommen. Bekannte Beispiele sind hier Azure Entry (früher Azure Active Directory) oder Auth0.

Das ganze Verfahren ist eine zusätzliche Schicht auf der bekannten OAuth2-Technologie mit Authorization Code und den Konzepten einer Authorization- und Token-URL. Der OpenID-Anbieter generiert auch den Access Token, den dann der HTTP-Client an den gewünschten Ressourcen-Server (hier Lobster Integration) übergibt. Der Ressourcen-Server prüft dann beim Erhalt des Requests, ob der Anfrager berechtigt ist, auf die Ressource zuzugreifen, wobei hier der vom OpenIP-Anbieter erhaltene Access Token verwendet wird.

OpenID selber macht keine Angaben dazu, wie ein Access Token zu prüfen ist. Als Best Practice hat sich aber das Verfahren über "Token Introspection" gemäß RFC7662 etabliert. Hier wird der Access Token im Industriestandard JSON Web Token (JWT) übermittelt. Dabei handelt es sich um eine Struktur, die als maschinenlesbares JSON vorliegt und alle notwendigen Informationen für den Empfänger enthält. Ein wesentlicher Aspekt ist hier, dass die Struktur vom OpenID-Anbieter digital signiert wurde und damit zum einen nicht mehr nachträglich verändert werden kann (Integrität) und zum anderen auch damit die Identität des Inhabers sichergestellt ist. Details zum Standard finden Sie beispielsweise unter https://jwt.io/. Mit den Informationen im JSON Web Token kann der Ressourcen-Server (hier Lobster Integration) nun über die enthaltenen JSON-Felder (im JSON-Web-Token--Jargon "Claims" genannt) Audience (aud) und Issuer (iss) prüfen, ob eine Berechtigung vorliegt. Weiterhin befinden sich im JSON Web Token auch noch Informationen, wann der Token ausgestellt wurde und wie lange er gültig ist. Bei der Audience (aus) handelt es sich in der Regel um einen eindeutigen Bezeichner, der in der OpenID-Anbieter-Konfiguration für den Anwendungsfall angegeben wird (z. B. die Application ID bei Azure), während der Issuer (iss) ein eindeutiger Bezeichner des OpenID-Anbieters ist.

Um die Vertrauenswürdigkeit des Tokens sicherzustellen, kann der Empfänger (hier Lobster Integration) mit dem öffentlich verfügbaren Zertifikat (des OpenID-Anbieters) die Signatur des JSON Web Tokens prüfen. Das ganze Verfahren basiert hier auf dem Vertrauen darauf, dass der Aussteller des Tokens berechtigt ist, den Endpunkt zu verwenden.

Konfiguration im HTTP-Kanal

Im oben beschriebenen Konzept ist die Rolle von Lobster Integration, wie bereits beschrieben, als HTTP-Endpunkt/Ressource-Server zu sehen. Anders als bei den HTTP-Authentifizierungs-Methoden Basic/Digest oder dem OAuth2-Server-Dienst, sind keine weiteren Informationen über den Benutzer vorhanden.

Die Konfiguration von OpenID ist einem HTTP-Kanal über folgenden Dialog vorzunehmen.