Erkundung der OpenID Connect-Konfiguration: Schlüssel-Felder und deren Verwendung

In der heutigen digitalen Welt ist die Authentifizierung zu einem zentralen Bestandteil der Sicherung von Websites und Anwendungen geworden. OpenID Connect (OIDC), eine Authentifizierungsebene auf Basis des OAuth 2.0-Protokolls, bietet eine standardisierte und einfache Möglichkeit zur Authentifizierung von Identitäten.

Die korrekte Integration von OIDC kann jedoch entmutigend sein, insbesondere für Neueinsteiger. Ein guter Ausgangspunkt ist oft die OIDC-Konfigurationsdatei, die normalerweise unter der URL {authServerUrl}/.well-known/openid-configuration zu finden ist und alle notwendigen Details zur Implementierung von OIDC-Diensten enthält.

Diese Anleitung zielt darauf ab, die Schlüssel-Felder in dieser Konfiguration zu erläutern, um Entwicklern zu helfen, deren Bedeutung und praktische Anwendungen zu verstehen, damit sie OIDC besser in ihre Projekte integrieren können.

Analyse der OIDC-Konfigurationsfelder#

Die OIDC-Konfiguration ist eine JSON-Datei, die in etwa wie folgt aussieht:

Als Nächstes gehen wir tiefer auf einige der wichtigsten Felder ein.

authorization_endpoint#

Bei der Integration von OIDC-Diensten besteht der erste Schritt normalerweise darin, Anfragen für die Benutzeranmeldung innerhalb der Anwendung zu bearbeiten. Dieser Prozess beinhaltet die Weiterleitung von Benutzern an den authorization_endpoint des Autorisierungsservers. Dieser Endpunkt ist die Serveradresse, an die Autorisierungsanfragen gesendet werden und die Benutzer zur Anmeldeseite für die Authentifizierung leitet.

Bei einer Anfrage an den authorization_endpoint muss sie für jede Autorisierung mit zusätzlichen Abfrageparametern konfiguriert werden:

• response_type: Gibt den Typ der zurückgegebenen Autorisierung an. Dies umfasst typischerweise „code“ (für den Autorisierungscode-Flow), „token“ (für den impliziten Flow) und „id_token token“ oder „code id_token“ (für den hybriden Flow), die im Feld response_types_supported der OIDC-Konfiguration zu finden sind.
• client_id: Eine eindeutige Kennung, die der Anwendung vom Autorisierungsserver zugewiesen wird, wenn die App registriert wird. Diese ID wird vom Autorisierungsserver verwendet, um die Clientanwendung zu erkennen, die die Anfrage initiert.
• scope: Definiert den angeforderten Zugriffsumfang und gibt die zugänglichen Ressourcen oder Benutzerinformationen an. Häufig vorkommende Scopes umfassen "openid" (verpflichtend), "profile" und "email", unter anderem. Sie können die unterstützten Scopes im Feld scopes_supported der OIDC-Konfiguration finden; verschiedene Scopes sollten durch Leerzeichen getrennt werden.
• redirect_uri: Nach der Anmeldung oder Autorisierung leitet der Autorisierungsserver den Benutzer zurück an die von der Anwendung angegebene URI. Diese URI muss genau mit der bei der Registrierung der Anwendung angegebenen URI übereinstimmen.
• state: Eine zufällig generierte Zeichenfolge, die verwendet wird, um den Client vor Cross-Site-Request-Forgery-Angriffen zu schützen. Die Konsistenz des Staates zwischen der Autorisierungsanfrage und dem Rückruf muss gewahrt werden, um die Sicherheit zu gewährleisten.

Diese Parameter ermöglichen es Entwicklern, das Verhalten von OIDC-Autorisierungsanfragen präzise zu steuern und sicherzustellen, dass diese sicher sind und den Anforderungen der Anwendung entsprechen.

Nachdem die Anfrage an den authorization_endpoint abgeschlossen ist und die Authentifizierung durchlaufen wurde, werden die Benutzer zur angegebenen redirect_uri weitergeleitet, die einen sehr wichtigen Abfrageparameter enthält—code. Dieser Autorisierungscode wird vom Autorisierungsserver bereitgestellt und ist das Ergebnis der Benutzer, die die Authentifizierung und Autorisierung der App durchgeführt haben, um auf ihre Informationen beim Autorisierungsserver zuzugreifen.

token_endpoint#

token_endpoint ist der Serverendpunkt, der vom Autorisierungsserver verwendet wird, um den oben genannten Autorisierungscode gegen Zugriffs- und Aktualisierungstoken auszutauschen. In der OAuth 2.0-Autorisierungscode-Flow ist dieser Schritt von entscheidender Bedeutung, da er den erhaltenen Autorisierungscode in tatsächliche Zugriffstoken umwandelt, die die App verwenden kann, um auf die geschützten Ressourcen des Benutzers zuzugreifen.

So wird der Austausch des Autorisierungscodes gegen Zugriffstoken implementiert (beachte, dass in diesem Beispiel die Authentifizierungsmethode client_secret_post verwendet wird. Für andere unterstützte Authentifizierungsmethoden siehe die spätere Analyse des

-Felds):

In diesem Code senden wir zunächst eine Anfrage an den token_endpoint mit der POST-Methode. Der Inhaltstyp wird auf application/x-www-form-urlencoded gesetzt, der von den meisten Autorisierungsservern verlangt wird. Der Anfragekörper enthält die folgenden Parameter:

• code: Der vom Autorisierungsserver erhaltene Autorisierungscode, der nach Abschluss der Autorisierung über die redirectUri zurückgegeben wird.
• redirect_uri: Diese selbe Redirect-URI wurde verwendet, um den Autorisierungscode zu erhalten, und dient zur Überprüfung der Legitimität der Anfrage.
• client_id: Die Client-Kennung der Anwendung, die verwendet wird, um die Anwendung, die die Anfrage stellt, zu identifizieren.
• client_secret: Das Client-Geheimnis der Anwendung, das zur Überprüfung der Identität der Anwendung verwendet wird.
• grant_type: Gibt den Autorisierungstyp an, hier verwenden wir "authorization_code", was darauf hinweist, dass das Zugriffstoken über den Autorisierungscode erhalten wird.

Diese Funktion wird asynchron ausgeführt und gibt ein JSON-Objekt zurück, das das Zugriffstoken enthält, das die Anwendung verwenden kann, um Benutzerdaten abzufragen oder andere Vorgänge durchzuführen.

userinfo_endpoint#

userinfo_endpoint ist der Serverendpunkt, der vom Autorisierungsserver verwendet wird, um detaillierte Informationen über authentifizierte Benutzer zu erhalten. Nachdem Benutzer erfolgreich autorisiert wurden und über den token_endpoint Zugriffstoken erhalten haben, kann die Anwendung diesen Endpunkt anfragen, um auf die Profilinformationen des Benutzers zuzugreifen, wie beispielsweise Benutzernamen und E-Mail-Adresse. Die spezifischen Informationen, die abgerufen werden, hängen von dem scope ab, der vom Benutzer in der Authentifizierungsanfrage angegeben wurde.

In dieser Funktion verwenden wir zunächst die GET-Methode, um den userinfo_endpoint anzufordern, einschließlich des Authorization-Felds im Anfrageheader, der aus token_type und accessToken besteht. Dies ist eine Standardvorgehensweise gemäß der OAuth 2.0-Spezifikation und gewährleistet das sichere Abrufen von Benutzerinformationen. Außerdem hängt der Umfang der über das Zugriffstoken zugänglichen Benutzerinformationen vollständig von den während der Autorisierungsinitiierung angenommenen Werte des scope-Parameters ab. Wird beispielsweise der email-Scope verwendet, sollte die Antwort die E-Mail-Adresse des Benutzers enthalten.

issuer & jwks_uri#

Der issuer identifiziert die URL des Autorisierungsservers, während die jwks_uri die URI für das JSON Web Key Set (JWKS) angibt, das eine Reihe von öffentlichen Schlüsseln enthält, die zur Überprüfung von JWT-Signaturen verwendet werden. Die Überprüfung des JWT-issuer und der Signatur sind grundlegende Schritte zur Gewährleistung der Tokensicherheit. In realen

Szenarien umfasst der Verifizierungsprozess jedoch typischerweise auch die Überprüfung des Gültigkeitszeitraums des Tokens, des Audiences, des Autorisierungsumfangs und anderer wichtiger Felder.

Der folgende Code demonstriert hauptsächlich, wie man issuer und jwks_uri gemeinsam verwendet, um ein JWT zu überprüfen:

scopes_supported & claims_supported#

Die claims_supported- und scopes_supported-Felder deklarieren die Benutzerattribute (Claims) und Zugriffs-Scopes (Scopes), die vom Autorisierungsserver unterstützt werden. Sie helfen Clients zu verstehen, welche Benutzerattribute und Zugriffs-Scopes vom Autorisierungsserver unterstützt werden, sodass Clients effektiv Autorisierungsanfragen erstellen und Antworten analysieren können.

Bei der Erstellung einer Autorisierungsanfrage können Clients den erforderlichen scope basierend auf den Anforderungen der Anwendung spezifizieren. Scope definiert die Ressourcen und Operationen, auf die der Client zugreifen möchte, wie beispielsweise openid, email, profile und andere.

Es ist wichtig zu beachten, dass die spezifischen Claims, die in jeder Autorisierungsanfrage zugänglich sind, je nach den zu Beginn der Authentifizierungsanfrage angegebenen Scope-Werten variieren. Der email-Scope gewährt beispielsweise Zugriff auf die E-Mail-Adresse des Benutzers, während der phone-Scope Zugriff auf dessen Telefonnummer gewährt. Daher sollten Clients den relevanten Scope sorgfältig auswählen, um den Anforderungen der Anwendung zu entsprechen, wenn sie eine Autorisierungsanfrage erstellen, damit sie die erforderlichen Benutzerattribute abrufen können:

token_endpoint_auth_methods_supported

#

Das

-Feld gibt die vom Token-Endpunkt unterstützten Authentifizierungsmethoden an. Diese Methoden werden vom Client verwendet, um sich beim Autorisierungsserver zu authentifizieren, wenn der Autorisierungscode gegen Zugriffstoken ausgetauscht wird.

Bei der Authentifizierung mit dem Token-Endpunkt umfassen häufige Authentifizierungsmethoden client_secret_post, client_secret_basic und client_secret_jwt.

• client_secret_post: Der Client verwendet seine Client-Kennung und sein Client-Geheimnis, um einen formularcodierten Körper zu erstellen, der als Teil des Anfragekörpers gesendet wird. Ein Beispiel für diese Methode haben wir bereits im Abschnitt über den token_endpoint oben gesehen.

• client_secret_basic: Der Client verwendet seine Client-Kennung und sein Client-Geheimnis, um einen Basis-Authentifizierungsheader zu erstellen, der dem Anfrageheader hinzugefügt wird.

• client_secret_jwt: Der Client verwendet ein JWT (JSON Web Token) als Client-Bestätigung zur Authentifizierung. Dieses JWT enthält die Client-Kennung und einige zusätzliche Metadaten und wird mit dem Client-Geheimnis signiert. Nach Erhalt der Anfrage überprüft der Autorisierungsserver die Identität des Clients durch Validierung der JWT-Signatur.

In praktischen Anwendungen müssen Clients die geeignete Authentifizierungsmethode basierend auf den vom Autorisierungsserver unterstützten Methoden auswählen und sicherstellen, dass die Authentifizierungsinformationen korrekt zur Anfrage hinzugefügt werden, um den Autorisierungscode sicher gegen Zugriffstoken auszutauschen.

Zusammenfassung#

Wir haben nun die wichtigsten Felder in der OIDC-Konfiguration untersucht und uns auf deren Zweck und Anwendungen konzentriert. Das Verständnis dieser Details wird dein Verständnis von OpenID Connect verbessern und dir ermöglichen, es effektiver in deine Projekte zu integrieren und zu nutzen. Mit diesem Wissen bist du besser gerüstet, um das volle Potenzial von OIDC für sicherere und effizientere Benutzerauthentifizierungslösungen auszuschöpfen.

Logto ist ein Authentifizierungsdienst, der auf OIDC basiert und eine umfassende Suite von SDKs in verschiedenen Sprachen sowie zahlreiche Integrationsanleitungen bietet. Damit kannst du OAuth / OIDC-Logins nahtlos in deine Anwendungen integrieren, und das in nur wenigen Minuten. Wenn du nach einem zuverlässigen und benutzerfreundlichen OIDC-Dienst suchst, probiere Logto noch heute aus!