Soziale Anmeldung mit OpenID Connect (OIDC) einrichten
Der offizielle Logto Connector für das OpenID Connect (OIDC) Protokoll.
Diese Anleitung setzt voraus, dass du ein grundlegendes Verständnis von Logto Connectors hast. Für diejenigen, die damit nicht vertraut sind, verweisen wir auf die Connectors Anleitung, um loszulegen.
Erste Schritte
Der OIDC Connector ermöglicht die Verbindung von Logto zu einem beliebigen sozialen Identitätsanbieter, der das OIDC-Protokoll unterstützt. Verwende den OIDC Connector, um deiner Anwendung zu ermöglichen:
- Soziale Anmeldebuttons hinzuzufügen
- Benutzerkonten mit sozialen Identitäten zu verknüpfen
- Benutzerprofilinformationen vom sozialen Anbieter zu synchronisieren
- Auf Drittanbieter-APIs zuzugreifen durch sichere Token-Speicherung im Logto Secret Vault für Automatisierungsaufgaben (z. B. Bearbeiten von Google Docs, Verwalten von Kalenderereignissen in deiner App)
Um diese Authentifizierungsfunktionen einzurichten, erstelle zuerst einen OIDC Connector in Logto:
- Gehe zu Logto-Konsole > Connector > Sozialer Connector.
- Klicke auf Sozialen Connector hinzufügen, wähle OIDC, klicke auf Weiter und folge dem Schritt-für-Schritt-Tutorial, um die Integration abzuschließen.
Der OIDC Connector ist eine besondere Art von Connector in Logto, du kannst mehrere auf dem OIDC-Protokoll basierende 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 du tun solltest, ist zu bestätigen, dass der Identitätsanbieter das OIDC-Protokoll unterstützt, da dies eine Voraussetzung für die Konfiguration eines gültigen Connectors ist. Folge dann den Anweisungen des Identitätsanbieters, um die entsprechende App für die OIDC-Autorisierung zu registrieren und zu erstellen.
Konfiguriere deinen Connector
Wir unterstützen AUSSCHLIESSLICH den "Authorization Code" Grant-Typ aus Sicherheitsgründen, und dieser passt perfekt zum Szenario von Logto.
clientId und clientSecret findest du auf der Detailseite deiner OIDC-App.
clientId: Die Client-ID ist ein eindeutiger Bezeichner, 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 zugewiesen wird. Die Client-Anwendung verwendet diesen geheimen Schlüssel, um sich beim Autorisierungsserver zu authentifizieren, wenn Zugangstokens angefordert werden. Das Client-Secret gilt als vertrauliche Information und sollte stets sicher aufbewahrt werden.
tokenEndpointAuthMethod: Die Authentifizierungsmethode für den Token-Endpunkt wird von der Client-Anwendung verwendet, um sich beim Autorisierungsserver zu authentifizieren, wenn Zugangstokens angefordert werden. 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 schaue in die entsprechende Dokumentation des OAuth 2.0-Dienstanbieters.
clientSecretJwtSigningAlgorithm (Optional): Nur erforderlich, wenn tokenEndpointAuthMethod auf client_secret_jwt gesetzt 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 bestimmte 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-Providers finden. Sie sollten in der Dokumentation des sozialen Anbieters verfügbar sein.
authenticationEndpoint: Dieser Endpunkt wird verwendet, um den Authentifizierungsprozess zu starten. 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 zum Zugriff auf die angeforderten Ressourcen verwendet werden kann. 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 die URL des Endpunkts, 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 ausgegeben werden. Die jwksUri wird von der vertrauenden Partei (RP) verwendet, um die öffentlichen Schlüssel zu erhalten, die vom IdP zum Signieren der JWTs verwendet werden, sodass die RP die Authentizität und Integrität der vom IdP empfangenen JWTs überprüfen kann.
issuer: Dies ist der eindeutige Bezeichner des IdP, der von der RP verwendet wird, um die vom IdP empfangenen JWTs zu überprüfen. Er ist in den JWTs als iss Anspruch (Claim) enthalten (ID-Token ist immer ein JWT). Der Wert des Issuers sollte mit der URL des Autorisierungsservers des IdP übereinstimmen und eine URI sein, der die RP vertraut. Wenn die RP ein JWT erhält, prü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 Wert des Issuers 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 bündeln. Details findest du unter OIDC Authentication Request. Du wirst vielleicht 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 verlagert. Also keine Sorge! Die zuvor erwähnten jwksUri und issuer sind ebenfalls in idTokenVerificationConfig enthalten.
Du fragst dich vielleicht, warum ein standardisiertes OIDC-Protokoll sowohl den Implicit- als auch den Hybrid-Flow unterstützt, der Logto-Connector jedoch nur den Authorization-Flow. Es wurde festgestellt, dass die Implicit- und Hybrid-Flows weniger sicher sind als der Authorization-Flow. Aufgrund des Fokus von Logto auf Sicherheit wird ausschließlich der Authorization-Flow unterstützt, um das höchste Sicherheitsniveau für die Nutzer zu gewährleisten, auch wenn dies etwas weniger bequem ist.
responseType und grantType können NUR FESTE Werte im "Authorization Code"-Flow haben, daher machen wir sie optional und Standardwerte werden automatisch ausgefüllt.
Für alle Flow-Typen haben wir einen OPTIONALEN customConfig-Schlüssel bereitgestellt, um deine individuellen Parameter einzutragen.
Jeder soziale Identitätsanbieter kann seine eigene Variante des OIDC-Standardprotokolls haben. Wenn dein gewünschter sozialer Identitätsanbieter strikt dem OIDC-Standardprotokoll folgt, musst du dich nicht um customConfig 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 |
| Eigenschaften von AuthRequestOptionalConfig | 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 |
| Eigenschaften von IdTokenVerificationConfig | 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 |
Weitere Details zu IdTokenVerificationConfig findest du hier.
Allgemeine Einstellungen
Hier sind einige allgemeine Einstellungen, die die Verbindung zu deinem Identitätsanbieter nicht blockieren, aber das Authentifizierungserlebnis für Endbenutzer beeinflussen können.
Name und Logo des Social-Buttons
Wenn du einen Social-Button auf deiner Anmeldeseite anzeigen möchtest, kannst du den Namen und das Logo (Dark Mode und Light Mode) des sozialen Identitätsanbieters festlegen. Dies hilft den Nutzern, die Option für die soziale Anmeldung zu erkennen.
Name des Identitätsanbieters
Jeder Social-Connector hat einen eindeutigen Identitätsanbieter (IdP)-Namen, um Benutzeridentitäten zu unterscheiden. Während gängige Connectoren einen festen IdP-Namen verwenden, benötigen benutzerdefinierte Connectoren einen eindeutigen Wert. Erfahre mehr über IdP-Namen für weitere Details.
Profilinformationen synchronisieren
Im OIDC-Connector kannst du die Richtlinie für das Synchronisieren von Profilinformationen wie Benutzernamen und Avataren festlegen. Wähle aus:
- Nur beim ersten Anmelden synchronisieren: Profilinformationen werden einmalig beim ersten Anmelden des Benutzers abgerufen.
- Immer beim Anmelden synchronisieren: Profilinformationen werden jedes Mal aktualisiert, wenn sich der Benutzer anmeldet.
Tokens speichern, um auf Drittanbieter-APIs zuzugreifen (Optional)
Wenn du auf die APIs des Identitätsanbieters zugreifen und Aktionen mit Benutzerautorisierung durchführen möchtest (entweder über Social Sign-In oder Account Linking), muss Logto bestimmte API-Berechtigungen erhalten und Tokens speichern.
- Füge die erforderlichen Berechtigungen im scope-Feld gemäß den obigen Anweisungen hinzu.
- Aktiviere Tokens für dauerhaften API-Zugriff speichern im Logto OIDC-Connector. Logto speichert Zugangstokens sicher im Secret Vault.
- Für standardisierte OAuth/OIDC-Identitätsanbieter muss der
offline_access-Scope enthalten sein, um ein Auffrischungstoken zu erhalten und wiederholte Benutzerzustimmungsaufforderungen zu vermeiden.
Halte dein Client-Secret sicher und veröffentliche es niemals im Client-seitigen Code. Wenn es kompromittiert wird, generiere sofort ein neues in den App-Einstellungen deines Identitätsanbieters.
OIDC-Connector nutzen
Sobald du einen OIDC-Connector erstellt und mit deinem Identitätsanbieter verbunden hast, kannst du ihn in deine Endbenutzer-Flows integrieren. Wähle die Optionen, die zu deinen Anforderungen passen:
Social Sign-In-Button aktivieren
- Gehe in der Logto-Konsole zu Anmeldeerlebnis > Registrierung und Anmeldung.
- Füge den OIDC-Connector im Abschnitt Social Sign-In hinzu, damit Benutzer sich mit deinem Identitätsanbieter authentifizieren können.
Erfahre mehr über die Social Sign-In-Erfahrung.
Ein soziales Konto verknüpfen oder trennen
Nutze die Account API, um ein benutzerdefiniertes Account Center in deiner App zu erstellen, das angemeldeten Benutzern das Verknüpfen oder Trennen ihrer sozialen Konten ermöglicht. Folge dem Account API-Tutorial
Es ist erlaubt, den OIDC-Connector nur für Account Linking und API-Zugriff zu aktivieren, ohne ihn für Social Sign-In zu aktivieren.
Auf APIs des Identitätsanbieters zugreifen und Aktionen durchführen
Deine Anwendung kann gespeicherte Zugangstokens aus dem Secret Vault abrufen, um die APIs deines Identitätsanbieters aufzurufen und Backend-Aufgaben zu automatisieren. Die spezifischen Möglichkeiten hängen von deinem Identitätsanbieter und den angeforderten Berechtigungen ab. Siehe die Anleitung zum Abrufen gespeicherter Tokens für den API-Zugriff.
Soziale Identität des Benutzers verwalten
Nachdem ein Benutzer sein soziales Konto verknüpft hat, können Administratoren diese Verbindung in der Logto-Konsole verwalten:
- Navigiere zu Logto-Konsole > Benutzerverwaltung und öffne das Profil des Benutzers.
- Unter Soziale Verbindungen finde den Eintrag des Identitätsanbieters und klicke auf Verwalten.
- Auf dieser Seite können Administratoren die soziale Verbindung des Benutzers verwalten, alle gewährten und synchronisierten Profilinformationen aus dem sozialen Konto einsehen und den Status des Zugangstokens überprüfen.
Einige Identitätsanbieter geben im Access Token Response keine spezifischen Scope-Informationen zurück, sodass Logto die Liste der vom Benutzer gewährten Berechtigungen nicht direkt anzeigen kann. Solange der Benutzer jedoch den angeforderten Berechtigungen während der Autorisierung zugestimmt hat, hat deine Anwendung beim Zugriff auf die OIDC-API die entsprechenden Berechtigungen.