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 folgende Möglichkeiten zu bieten:
- Soziale Anmeldebuttons hinzufügen
- Benutzerkonten mit sozialen Identitäten verknüpfen
- Benutzerprofilinformationen vom sozialen Anbieter synchronisieren
- Zugriff auf Drittanbieter-APIs 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 > Social Connector.
- Klicke auf Social 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 Connectors 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 geheimer 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 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 beim Token-Request an den Autorisierungsserver gesendet wird.
scope: Der Scope-Parameter wird verwendet, um die Menge an Ressourcen und Berechtigungen (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 (ID-Token) zu erhalten, das zum Zugriff auf die angeforderten Ressourcen verwendet werden kann. Die Client-Anwendung sendet typischerweise eine Anfrage mit einem Grant-Typ und einem Autorisierungscode an den Token-Endpunkt, um ein ID-Token zu erhalten.
jwksUri: Dies ist die URL, unter der das JSON Web Key Set (JWKS) des sozialen Identitätsanbieters (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 des IdP zu erhalten, mit denen die JWTs signiert 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 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 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 Standard-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 mit dem "Authorization Code"-Flow sein, daher machen wir sie optional und Standardwerte werden automatisch ausgefüllt.
Für alle Flow-Typen stellen wir einen OPTIONALEN customConfig-Schlüssel bereit, 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 die Authentifizierungserfahrung der Endbenutzer beeinflussen können.
Name und Logo des sozialen 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 Benutzern, die soziale Anmeldeoption zu erkennen.
Name des Identitätsanbieters
Jeder Social Connector hat einen eindeutigen Identitätsanbieter-Namen (IdP), 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 bei Registrierung synchronisieren: Profilinformationen werden einmalig abgerufen, wenn sich der Benutzer zum ersten Mal anmeldet.
- Immer bei Anmeldung 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 (sei es über soziale Anmeldung oder Kontoverknüpfung), muss Logto bestimmte API-Berechtigungen (Scopes) erhalten und Tokens speichern.
- Füge die erforderlichen Scopes 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 Scope
offline_accessenthalten sein, um ein Auffrischungstoken (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.
Nutze den OIDC-Connector
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 Anmeldeerfahrung > Registrierung und Anmeldung.
- Füge den OIDC-Connector im Abschnitt Soziale Anmeldung 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 ermöglicht, ihre sozialen Konten zu verknüpfen oder zu trennen. Folge dem Account API-Tutorial
Es ist erlaubt, den OIDC-Connector nur für Kontoverknüpfung und API-Zugriff zu aktivieren, ohne ihn für die soziale Anmeldung zu aktivieren.
Auf Identitätsanbieter-APIs 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 Scopes 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 vom Benutzer gewährten Berechtigungen nicht direkt anzeigen kann. Solange der Benutzer jedoch den angeforderten Scopes während der Autorisierung zugestimmt hat, hat deine Anwendung die entsprechenden Berechtigungen beim Zugriff auf die OIDC-API.