Was ist OIDC: Von warum wir es brauchen bis wie es funktioniert

OpenID Connect (OIDC) Definition#

OpenID Connect (OIDC) ist ein Identitätsauthentifizierungsprotokoll, das auf OAuth 2.0 aufgebaut ist. Während OAuth 2.0 nur Autorisierung bietet, fügt OIDC Authentifizierungsfunktionen hinzu und bietet eine standardisiertere Lösung für Benutzerautorisierungs- und Authentifizierungsszenarien.

Einfach ausgedrückt: OIDC = Autorisierungsprotokoll + Identitätsauthentifizierung.

Warum wird OIDC benötigt?#

Um zu verstehen, warum OIDC benötigt wird, lassen Sie uns zunächst die Kernkonzepte und den Arbeitsablauf von OAuth 2.0 sowie seine Einschränkungen in praktischen Anwendungen erkunden. Durch die Analyse spezifischer Szenarien werden wir sehen, warum wir OIDC über OAuth 2.0 hinaus benötigen.

Schlüsselkonzepte und Autorisierungsfluss von OAuth 2.0#

OAuth 2.0 (Open Authorization) ist ein Autorisierungsprotokoll, das es Benutzern ermöglicht, Drittanwendungen Zugriff auf ihre Ressourcen zu gewähren, ohne ihre Anmeldedaten wie Benutzernamen und Passwörter zu teilen. Es betrifft vier Hauptrollen:

• Ressourceneigentümer: Der Benutzer, dem die Ressourcen gehören
• Ressourcenserver: Der Server, der Benutzerressourcen speichert
• Client: Die Drittanwendung, die Zugriff auf Benutzerressourcen anfordert
• Autorisierungsserver: Der Server, der die Identität des Benutzers überprüft und Zugriffstoken ausstellt

Ein typischer OAuth 2.0-Autorisierungsfluss funktioniert folgendermaßen:

Wie gezeigt, kümmert sich OAuth 2.0 hauptsächlich um die Ausgabe von Zugriffstoken für Drittanbieter-Clients, um auf Benutzerressourcen zuzugreifen.

Die Einschränkung von OAuth 2.0#

Das OAuth 2.0-Protokoll konzentriert sich nur auf die Ausgabe von Zugriffstoken. Der Ressourcenserver validiert diese Token und gibt die autorisierten Ressourcen zurück. Der Ressourcenserver kennt jedoch nicht die Identität des Benutzers.

Dies war kein signifikantes Problem im frühen Internet-Ökosystem.

Allerdings haben sich Plattformen wie Google, Facebook, Twitter und Github weiterentwickelt und begannen, reichhaltige Benutzerressourcen anzubieten, die für Drittanwendungen wertvoll wurden.

Während OAuth 2.0 hervorragend bei der Autorisierung von Drittanbieterzugriffen auf Benutzerressourcen ist, weist es Einschränkungen auf. Ein typisches Szenario ist: Da auch Benutzerinformationen eine Ressource sind, geben verschiedene Plattformen (wie Google, Facebook, Twitter) Benutzerinformationen in unterschiedlichen Formaten zurück, was für Entwickler Herausforderungen schafft.

OIDC wurde geschaffen, um diese Herausforderungen anzugehen.

Rollen in OIDC#

Um die Benutzerauthentifizierung auf Basis von OAuth 2.0 zu ermöglichen und dessen Einschränkungen anzusprechen, führte OIDC drei Rollen ein:

• Endnutzer (EU): Der Endbenutzer, entspricht dem Ressourceneigentümer von OAuth 2.0
• Vertrausender Dritter (RP): Die abhängige Partei, entspricht dem Client von OAuth 2.0
• OpenID-Anbieter (OP): Der Identitätsauthentifizierungsdienstleister, entspricht dem Autorisierungsserver und Ressourcenserver von OAuth 2.0

Der OP ist die Kernrolle, die sowohl die Autorisierungsfunktionalität von OAuth 2.0 bietet als auch Benutzerinformationen als separate Ressource behandelt.

Wie funktioniert OIDC?#

Der Authentifizierungsprozess von OIDC ähnelt OAuth 2.0, aber da OP die Rollen des Autorisierungsservers und des Ressourcenservers kombiniert, gibt er sowohl ein Zugangstoken als auch ein ID-Token zurück. Das ID-Token enthält Benutzeridentitätsinformationen, und der RP kann die Identität des Benutzers durch Validierung des ID-Tokens überprüfen.

Ein typischer Arbeitsablauf sieht folgendermaßen aus:

Dies standardisiert, wie Benutzerinformationen auf verschiedenen Plattformen bezogen werden, und eliminiert die Notwendigkeit für Drittanwendungen, plattformspezifische Unterschiede zu handhaben.

ID-Token (Identitätstoken) in OIDC#

Wenn Benutzer Drittanwendungen autorisieren, gibt der OP sowohl ein OAuth 2.0-Zugangstoken als auch ein JWT-formatiges ID-Token zurück. Dieses ID-Token enthält Benutzeridentitätsinformationen wie Benutzer-ID, Benutzername, E-Mail und Avatar. Der RP kann die Identität des Benutzers bestätigen, indem er das ID-Token validiert.

Als JWT enthält das ID-Token standardisierte Claims, einschließlich dieser erforderlichen Kernansprüche:

• iss (Issuer): Eindeutiger Bezeichner des OpenID-Anbieters, der das ID-Token ausstellt
• sub (Subject): Eindeutiger Bezeichner des Benutzers
• aud (Audience): Bezeichner der Client-Anwendung, die das ID-Token empfängt
• exp (Expiration Time): Wann das ID-Token abläuft
• iat (Issued At): Wann das ID-Token ausgestellt wurde

Für detaillierte Informationen über ID-Token, siehe: ID-Token.

Userinfo-Endpunkt#

Der Userinfo-Endpunkt ist eine standardisierte HTTP-API, die vom OP bereitgestellt wird, um authentifizierte Benutzerdetails zu erhalten. Durch das Senden von GET- oder POST-Anfragen mit einem Zugangstoken zu diesem Endpunkt können Sie Benutzerinformationen im JSON-Format erhalten. Die zurückgegebenen Daten umfassen standardisierte Felder wie eindeutige Benutzer-ID (sub), Benutzername (name), E-Mail und Bild.

Der Prozess des Erhaltens von Nutzerinformationen folgt dem gleichen Muster wie der Zugriff auf geschützte Ressourcen in OAuth 2.0. Normalerweise sind die vom Userinfo-Endpunkt erhaltenen Benutzerinformationen umfassender als die im ID-Token, da das ID-Token hauptsächlich der Identitätsauthentifizierung und den grundlegenden Benutzerinformationen dient.

Für detaillierte Informationen über den Userinfo-Endpunkt, siehe: Userinfo-Endpunkt.

Beachten Sie, dass die Benutzerinformationen, die Sie vom Userinfo-Endpunkt erhalten, von den während der Autorisierung angeforderten Scopes und gewährten Berechtigungen abhängen.

Scopes in OIDC#

Scopes in OIDC definieren, auf welche Benutzerinformationen der RP zugreifen kann. OIDC definiert standardisierte Scopes, wobei der openid-Scope in OIDC-Authentifizierungsabläufen obligatorisch ist.

Häufig verwendete standardisierte Scopes umfassen:

• openid: Gibt eine OIDC-Authentifizierungsanforderung an
• profile: Grundlegende Benutzerinformationen wie Name und Avatar
• email: E-Mail-Informationen des Benutzers
• phone: Telefonnummer des Benutzers
• address: Adressinformationen des Benutzers

Verschiedene Scopes geben unterschiedliche Benutzerinformationen zurück. Wenn openid profile email angefordert wird, werden grundlegende Benutzerinformationen und E-Mails im ID-Token und in den Userinfo zurückgegeben, während openid profile email phone address auch Telefonnummer und Adressinformationen enthält.

Identitätsmanagement basierend auf OIDC#

OIDC ist nicht nur ein Authentifizierungsprotokoll; es ist ein leistungsstarkes Werkzeug zum Aufbau flexibler, skalierbarer Identitätsmanagementsysteme. Durch das Hinzufügen einer Authentifizierungsschicht zu OAuth 2.0, die Standardisierung von Benutzerinformationsressourcen und das Fundament für erweiterte Identitätsverwaltungsfunktionen legt OIDC die Grundlage für verschiedene Identitätsmanagementszenarien:

• Single Sign-On (SSO): OIDC unterstützt von Natur aus SSO durch erweiterte Benutzersitzungsinformationen, die einheitliches Login-Statusmanagement und identitätsübergreifende Anwendungsfreigabe ermöglichen
• Organisationsstrukturmanagement: Erweiterte Benutzerorganisationsinformationen können komplexe organisatorische Strukturen verwalten, einschließlich Abteilungshierarchien und Benutzergruppenbeziehungen
• Berechtigungsmanagement: Erweiterte Benutzerberechtigungsattribute ermöglichen eine feingranulare Ressourcenzugriffskontrolle, einschließlich Rolleninformationen und Berechtigungskonfiguration

OIDCs Flexibilität passt sich an die sich entwickelnden Identitätsmanagementbedürfnisse an. Viele Identitätsmanagementsysteme basieren auf OIDC, wie z. B. Logto, das SSO, Organisationsmanagement und Berechtigungsmanagement bietet.