Soziale Anmeldung mit OpenID Connect (OIDC) einrichten
Der offizielle Logto-Connector für das OpenID Connect (OIDC)-Protokoll.
In diesem Leitfaden gehen wir davon aus, dass du grundlegende Kenntnisse über Logto Connectors hast. Falls nicht, schaue dir den Leitfaden Connectors konfigurieren an, um loszulegen.
Erste Schritte
Der OIDC-Connector ermöglicht Logto die Verbindung zu einem beliebigen sozialen Identitätsanbieter, der das OIDC-Protokoll unterstützt.
ℹ️ Hinweis
Der OIDC-Connector ist eine spezielle Art von Connector in Logto, du kannst einige OIDC-basierte Connectoren hinzufügen.
Erstelle deine OIDC-App
Wenn du diese Seite öffnest, gehen wir davon aus, dass du bereits weißt, mit welchem sozialen Identitätsanbieter du dich verbinden möchtest. Das Erste, was zu tun ist, ist zu bestätigen, dass der Identitätsanbieter das OIDC-Protokoll unterstützt, was eine Voraussetzung für die Konfiguration eines gültigen Connectors ist. Befolge dann die Anweisungen des Identitätsanbieters, um die relevante App für die OIDC-Autorisierung zu registrieren und zu erstellen.
Konfiguriere deinen Connector
Wir unterstützen NUR den "Authorization Code"-Grant-Typ aus Sicherheitsgründen, und er passt perfekt zu Logtos Szenario.
clientId
und clientSecret
findest du auf der Detailseite deiner OIDC-Apps.
clientId: Die Client-ID ist ein eindeutiger Identifikator, der die Client-Anwendung während der Registrierung beim Autorisierungsserver identifiziert. Diese ID wird vom Autorisierungsserver verwendet, um die Identität der Client-Anwendung zu überprüfen und alle autorisierten Zugangstokens mit dieser spezifischen Client-Anwendung zu verknüpfen.
clientSecret: Das Client-Secret ist ein vertraulicher Schlüssel, der der Client-Anwendung vom Autorisierungsserver während der Registrierung ausgestellt wird. Die Client-Anwendung verwendet diesen geheimen Schlüssel, um sich beim Autorisierungsserver zu authentifizieren, wenn sie Zugangstokens anfordert. Das Client-Secret wird als vertrauliche Information betrachtet und sollte jederzeit sicher aufbewahrt werden.
tokenEndpointAuthMethod: Die Authentifizierungsmethode des Token-Endpunkts wird von der Client-Anwendung verwendet, um sich beim Autorisierungsserver zu authentifizieren, wenn sie Zugangstokens anfordert. Um unterstützte Methoden zu entdecken, konsultiere das Feld token_endpoint_auth_methods_supported
, das am OpenID Connect-Discovery-Endpunkt des OAuth 2.0-Dienstanbieters verfügbar ist, oder beziehe dich auf die relevante Dokumentation des OAuth 2.0-Dienstanbieters.
clientSecretJwtSigningAlgorithm (Optional): Nur erforderlich, wenn tokenEndpointAuthMethod
client_secret_jwt
ist. Der Client-Secret-JWT-Signaturalgorithmus wird von der Client-Anwendung verwendet, um das JWT zu signieren, das während der Token-Anfrage an den Autorisierungsserver gesendet wird.
scope: Der Scope-Parameter wird verwendet, um die Menge an Ressourcen und Berechtigungen anzugeben, auf die die Client-Anwendung zugreifen möchte. Der Scope-Parameter wird typischerweise als durch Leerzeichen getrennte Liste von Werten definiert, die spezifische Berechtigungen darstellen. Zum Beispiel könnte ein Scope-Wert von "read write" anzeigen, dass die Client-Anwendung Lese- und Schreibzugriff auf die Daten eines Benutzers anfordert.
Du solltest authorizationEndpoint
, tokenEndpoint
, jwksUri
und issuer
als Konfigurationsinformationen des OpenID-Anbieters finden. Sie sollten in der Dokumentation des sozialen Anbieters verfügbar sein.
authenticationEndpoint: Dieser Endpunkt wird verwendet, um den Authentifizierungsprozess zu initiieren. Der Authentifizierungsprozess beinhaltet typischerweise, dass sich der Benutzer anmeldet und der Client-Anwendung die Berechtigung erteilt, auf seine Ressourcen zuzugreifen.
tokenEndpoint: Dieser Endpunkt wird von der Client-Anwendung verwendet, um ein ID-Token zu erhalten, das verwendet werden kann, um auf die angeforderten Ressourcen zuzugreifen. Die Client-Anwendung sendet typischerweise eine Anfrage an den Token-Endpunkt mit einem Grant-Typ und einem Autorisierungscode, um ein ID-Token zu erhalten.
jwksUri: Dies ist der URL-Endpunkt, an dem das JSON Web Key Set (JWKS) des sozialen Identitätsanbieters (kurz IdP) abgerufen werden kann. Das JWKS ist eine Sammlung kryptografischer Schlüssel, die der IdP verwendet, um JSON Web Tokens (JWTs) zu signieren und zu verifizieren, die während des Authentifizierungsprozesses ausgestellt werden. Die jwksUri
wird von der vertrauenden Partei (RP) verwendet, um die öffentlichen Schlüssel zu erhalten, die vom IdP verwendet werden, um die JWTs zu signieren, sodass die RP die Authentizität und Integrität der vom IdP empfangenen JWTs überprüfen kann.
issuer: Dies ist der eindeutige Identifikator des IdP, der von der RP verwendet wird, um die vom IdP empfangenen JWTs zu überprüfen. Es ist in den JWTs als iss
Anspruch enthalten (ID-Token ist immer ein JWT). Der Ausstellerwert sollte mit der URL des Autorisierungsservers des IdP übereinstimmen und es sollte eine URI sein, der die RP vertraut. Wenn die RP ein JWT erhält, überprüft sie den iss
-Anspruch, um sicherzustellen, dass es von einem vertrauenswürdigen IdP ausgestellt wurde und dass das JWT für die Verwendung mit der RP bestimmt ist.
Zusammen bieten jwksUri
und issuer
einen sicheren Mechanismus für die RP, um die Identität des Endbenutzers während des Authentifizierungsprozesses zu überprüfen. Durch die Verwendung der von der jwksUri
erhaltenen öffentlichen Schlüssel kann die RP die Authentizität und Integrität der vom IdP ausgestellten JWTs überprüfen. Der Ausstellerwert stellt sicher, dass die RP nur JWTs akzeptiert, die von einem vertrauenswürdigen IdP ausgestellt wurden und dass die JWTs für die Verwendung mit der RP bestimmt sind.
Da immer eine Authentifizierungsanfrage erforderlich ist, wird ein authRequestOptionalConfig
bereitgestellt, um alle optionalen Konfigurationen zu umfassen. Details findest du unter OIDC Authentication Request. Du wirst vielleicht auch feststellen, dass nonce
in dieser Konfiguration fehlt. Da nonce
für jede Anfrage identisch sein sollte, haben wir die Generierung von nonce
in die Code-Implementierung aufgenommen. Also mach dir keine Sorgen darüber! Die zuvor erwähnten jwksUri
und issuer
sind ebenfalls in idTokenVerificationConfig
enthalten.
Du fragst dich vielleicht, warum ein standardmäßiges OIDC-Protokoll sowohl die impliziten als auch die hybriden Flows unterstützt, während der Logto-Connector nur den Autorisierungs-Flow unterstützt. Es wurde festgestellt, dass die impliziten und hybriden Flows weniger sicher sind als der Autorisierungs-Flow. Aufgrund von Logtos Fokus auf Sicherheit unterstützt es nur den Autorisierungs-Flow für das höchste Sicherheitsniveau für seine Benutzer, trotz seiner etwas weniger bequemen Natur.
responseType
und grantType
können NUR feste Werte mit dem "Authorization Code"-Flow sein, daher machen wir sie optional und Standardwerte werden automatisch ausgefüllt.
ℹ️ Hinweis
Für alle Flow-Typen haben wir einen OPTIONALEN
customConfig
-Schlüssel bereitgestellt, um deine benutzerdefinierten Parameter einzufügen. Jeder soziale Identitätsanbieter könnte seine eigene Variante des OIDC-Standardprotokolls haben. Wenn dein gewünschter sozialer Identitätsanbieter strikt am OIDC-Standardprotokoll festhält, musst du dich nicht umcustomConfig
kümmern.
Konfigurationstypen
Name | Typ | Erforderlich |
---|---|---|
scope | string | Ja |
clientId | string | Ja |
clientSecret | string | Ja |
authorizationEndpoint | string | Ja |
tokenEndpoint | string | Ja |
idTokenVerificationConfig | IdTokenVerificationConfig | Ja |
authRequestOptionalConfig | AuthRequestOptionalConfig | Nein |
customConfig | Record<string, string> | Nein |
AuthRequestOptionalConfig Eigenschaften | Typ | Erforderlich |
---|---|---|
responseType | string | Nein |
tokenEndpoint | string | Nein |
responseMode | string | Nein |
display | string | Nein |
prompt | string | Nein |
maxAge | string | Nein |
uiLocales | string | Nein |
idTokenHint | string | Nein |
loginHint | string | Nein |
acrValues | string | Nein |
IdTokenVerificationConfig Eigenschaften | Typ | Erforderlich |
---|---|---|
jwksUri | string | Ja |
issuer | string | string[] | Nein |
audience | string | string[] | Nein |
algorithms | string[] | Nein |
clockTolerance | string | number | Nein |
crit | Record<string, string | boolean> | Nein |
currentDate | Date | Nein |
maxTokenAge | string | number | Nein |
subject | string | Nein |
typ | string | Nein |
Siehe hier für weitere Details zu IdTokenVerificationConfig
.