OIDC – OpenID Connect

OpenID Connect ist eine Erweiterung von OAuth 2.0, die das OAuth-Protokoll um eine Identitätsschicht ergänzt. Sie ermöglicht es Benutzern, sich mit ihren Anmeldedaten beim Identitätsanbieter (IdP) zu authentifizieren und dann Anwendungen von Drittanbietern zu autorisieren, auf ihre Identitätsinformationen (z. B. ihren Namen und ihre E-Mail-Adresse) sowie auf andere Ressourcen zuzugreifen, für die der Benutzer eine Zugriffsberechtigung erteilt hat.

OpenID Connect ist eine Erweiterung von OAuth 2.0, die das Protokoll um eine Identitätsschicht ergänzt. Sie ermöglicht es Benutzern, sich mit ihren Anmeldedaten beim Identitätsanbieter (IdP) zu authentifizieren, und autorisiert dann Anwendungen von Drittanbietern, auf ihre Identitätsinformationen (wie Name und E-Mail-Adresse) sowie auf andere Ressourcen zuzugreifen, für die der Benutzer eine Zugriffsberechtigung erteilt hat. Diese Identitätsinformationen werden in Form eines JSON-Web-Tokens (JWT), genannt ID-Token, übergeben.

Kann OIDC im Hintergrund laufen?

OpenID Connect ist eine Erweiterung von OAuth 2.0, die dem Protokoll eine Identitätsschicht hinzufügt und auch für interaktive webbasierte Szenarien verwendet wird.

OpenID Connect im Detail

OpenID Connect (OIDC) ist eine Erweiterung von OAuth 2.0, die das Protokoll um eine Identitätsschicht ergänzt. Sie ermöglicht es Benutzern, sich mit ihren Anmeldedaten beim Identitätsanbieter (IdP) zu authentifizieren und dann Anwendungen von Drittanbietern zu autorisieren, auf ihre Identitätsinformationen (z. B. ihren Namen und ihre E-Mail-Adresse) sowie auf andere Ressourcen zuzugreifen, für die der Benutzer eine Zugangsberechtigung erteilt hat.

Bei OIDC wird der Benutzer zur Authentifizierung an den IdP weitergeleitet. Danach sendet der IdP ein ID-Token zurück, bei dem es sich um ein JSON-Web-Token (JWT) handelt, das Identitätsinformationen wie Name und E-Mail-Adresse enthält. Dieses Token kann zur Authentifizierung des Benutzers und zum Abrufen von Benutzerinformationen in der Anwendung verwendet werden.

OpenID Connect führt auch das Konzept der Bereiche (Scopes) ein, die verwendet werden, um bestimmte Arten von Informationen über den Benutzer anzufordern. Zum Beispiel kann eine Anwendung den Bereich „Profil“ anfordern, um den Namen und die E-Mail-Adresse des Benutzers abzurufen, oder den Bereich „E-Mail“, um nur die E-Mail-Adresse des Benutzers abzurufen.

Der Hauptvorteil von OpenID Connect gegenüber OAuth allein ist, dass es eine Standardmethode zur Authentifizierung von Benutzern und zum Abrufen von Benutzerinformationen bietet. Es bietet eine einheitliche Art der Authentifizierung und Autorisierung, die über mehrere Anwendungen und Dienste hinweg verwendet werden kann. Durch die Bereitstellung eines Identitäts-Tokens kann die Anwendung außerdem die Identität des Benutzers bestätigen und Benutzerinformationen auf standardisierte Weise abrufen.

Es ist wichtig zu beachten, dass OIDC auf OAuth aufbaut, also denselben Mechanismus von Zugriffstoken für den Zugriff auf Benutzerressourcen verwendet und beide JWT als Format für das Token verwenden können. Außerdem werden dieselben Abläufe und Gewährungstypen wie bei OAuth verwendet, mit dem Zusatz, dass der Authentifizierungsschritt vor dem Autorisierungsschritt erfolgt.

OIDC definiert mehrere verschiedene „Flows“, die verwendet werden können, um ein ID-Token und ein Zugriffstoken zu erhalten. Die gängigsten davon sind:

• Authorization Code Flow: Dieser Fluss ähnelt dem Autorisierungscodefluss in OAuth 2.0 und wird verwendet, wenn der Benutzer beim Client (z. B. einer Webanwendung) anwesend ist und mit ihm interagieren kann. Der Benutzer wird zur Authentifizierung an den IdP weitergeleitet. Danach sendet der IdP einen Autorisierungscode an die Client-Anwendung zurück, der Client tauscht diesen Code dann gegen ein ID-Token und ein Zugriffstoken aus.
• Implicit Flow: Dieser Fluss ähnelt dem Implicit Flow in OAuth 2.0 und wird verwendet, wenn der Client ein öffentlicher Client ist (z. B. eine einseitige JavaScript-Anwendung), der nicht in der Lage ist, ein Client-Geheimnis zu wahren. Der Benutzer wird zur Authentifizierung an den IdP weitergeleitet. Danach sendet der IdP ein ID-Token und ein Zugriffstoken direkt an den Client zurück.
• Hybrid Flow: Dieser Fluss kombiniert Aspekte des Autorisierungscodeflusses und des impliziten Flusses und kann zur Rückgabe eines ID-Tokens, eines Zugriffstokens und/oder eines Autorisierungscodes verwendet werden.

Wenn eine Client-Anwendung ein ID-Token anfordert, führt der IdP eine Benutzerauthentifizierung durch und erstellt dann ein ID-Token, das ein JWT ist; dieses Token wird an den Client zurückgeschickt. Dieses Token wird an den Client zurückgeschickt. Das ID-Token enthält eine Reihe von Claims, d. h. Name-Wert-Paare, die Informationen über den Benutzer enthalten. Das ID-Token enthält den eindeutigen Identifikator des Benutzers (sub claim), die IDP, die es ausgestellt hat (iss claim), das Zielpublikum (aud claim) und die Ablaufzeit des Tokens (exp claim).

Um ein Zugangstoken zu erhalten, muss die Client-Anwendung das ID-Token dem Autorisierungsserver vorlegen. Der Server validiert dann das ID-Token und prüft, ob es noch gültig ist und ob es für diesen Client und diese Zielgruppe ausgestellt worden ist.

Zusätzlich zu den Abläufen definiert das Protokoll mehrere Endpunkte, d. h. URLs, die zum Abrufen und Aktualisieren der Token verwendet werden. Der Endpunkt userinfo ist einer davon und ermöglicht es dem Client, zusätzliche Informationen über den Benutzer zu erhalten. Der Userinfo-Endpunkt ist geschützt, der Client muss ein gültiges Zugangstoken vorlegen, um die Informationen zu erhalten.

OIDC definiert auch einen Entdeckungsmechanismus, der es den Clients erlaubt, die Endpunkte und die Konfiguration des IdPs, den sie benutzen wollen, dynamisch zu entdecken. Dies erlaubt es den Clients, mit mehreren IdPs zu arbeiten und erlaubt es den IdPs auch, ihre Konfiguration zu ändern, ohne die Clients zu beeinflussen.

Zusammenfassend lässt sich sagen, dass OpenID Connect ein offener Standard ist, der eine Möglichkeit bietet, Benutzer zu authentifizieren und Benutzerinformationen auf eine standardisierte Weise zu erhalten. Er baut auf OAuth 2.0 auf und verwendet dieselben Abläufe und Token, fügt aber ein zusätzliches ID-Token hinzu, das Benutzerinformationen und Authentifizierungsinformationen enthält. Außerdem definiert er Standardendpunkte für den Erhalt und die Aktualisierung von Token sowie zusätzliche Benutzerinformationen und einen Erkennungsmechanismus für Clients, um die IdP-Konfiguration zu ermitteln.

Vorteile von OpenID Connect

• Einfach und leichtgewichtig: OIDC basiert auf JSON, wodurch es einfacher zu parsen und zu verarbeiten ist als XML-basierte Protokolle wie SAML. Es ist auch einfacher zu implementieren als SAML, insbesondere für Entwickler, die mit dem Protokoll nicht vertraut sind.
• Authentifizierung und Autorisierung in einem Protokoll: Mit OIDC werden Authentifizierung und Autorisierung zusammen in einem Protokoll behandelt, was die Entwicklung und Integration mit anderen Systemen vereinfachen kann.
  JSON Web Token(JWT)-Format: OIDC verwendet JWT als Format für das ID-Token, wodurch die Verarbeitung und Validierung des Tokens vereinfacht wird.
• OAuth 2.0-Grundlage: OIDC baut auf OAuth 2.0 auf, so dass dieselben Datenflüsse, Zugriffstoken und andere Bausteine genutzt werden können und Abwärtskompatibilität mit OAuth gewährleistet ist.
• Erkennungsmechanismus: Der Erkennungsmechanismus ermöglicht es den Clients, die Endpunkte und die Konfiguration des IdP, den sie verwenden möchten, dynamisch zu erkennen. Dies ermöglicht es den Clients, mit mehreren IdPs zu arbeiten, und erlaubt es den IdPs auch, ihre Konfiguration zu ändern, ohne dass dies Auswirkungen auf die Clients hat.

Nachteile von OpenID Connect

• Begrenzte Flexibilität: OIDC ist für die Authentifizierung von Benutzern und den Erhalt von Benutzerinformationen auf standardisierte Weise gedacht und bietet daher möglicherweise nicht das gleiche Maß an Flexibilität und Funktionalität wie einige andere Protokolle wie SAML.
• Keine einmalige Abmeldung: OIDC bietet keinen Standardmechanismus für die einmalige Abmeldung, diese müsste manuell vom Client und dem IdP vorgenommen werden.
• Fehlende Unterstützung für andere Authentifizierungsmethoden: OIDC bietet nur einen Standard für die Benutzerauthentifizierung durch ein Benutzer-Passwort-Paar, es unterstützt keine anderen Formen der Authentifizierung wie Smartcards, Biometrie und Multi-Faktor-Authentifizierung.
• Browser-zentriert: OIDC ist in erster Linie für webbasierte Szenarien gedacht, bei denen ein Benutzer mit einer Webanwendung in einem Browser interagiert, und eignet sich möglicherweise nicht für andere Arten von Clients.

Es ist wichtig zu beachten, dass OIDC für webbasierte Szenarien gedacht ist, in denen ein Benutzer mit einer Webanwendung in einem Browser interagiert, so dass sein Hauptanwendungsfall die Authentifizierung und Autorisierung von Benutzern ist. Es ist möglicherweise nicht für andere Arten von Clients geeignet, aber es ist eine gute Wahl für Szenarien, in denen Benutzerauthentifizierung, Autorisierung und einfache Integration wichtig sind.