Soziale Anmeldung mit OAuth 2.0-Protokoll einrichten

Der offizielle Logto Connector für das OAuth 2.0-Protokoll.

tipp:

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 OAuth Connector ermöglicht Logtos Verbindung zu einem beliebigen sozialen Identitätsanbieter, der das OAuth 2.0-Protokoll unterstützt.

hinweis:

Der OAuth Connector ist eine spezielle Art von Connector in Logto, du kannst einige auf dem OAuth-Protokoll basierende Connectors hinzufügen.

Erstelle deine OAuth-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 OAuth-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 relevante App für die OAuth-Autorisierung zu registrieren und zu erstellen.

Konfiguriere deinen Connector

Wir unterstützen aus Sicherheitsgründen NUR den "Authorization Code"-Grant-Typ, und er passt perfekt zu Logtos Szenario.

clientId und clientSecret findest du auf der Detailseite deiner OAuth-Apps.

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 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 der 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 und userInfoEndpoint in der Dokumentation des sozialen Anbieters finden.

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 Zugangstoken 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 Zugangstoken zu erhalten.

userInfoEndpoint: Dieser Endpunkt wird von der Client-Anwendung verwendet, um zusätzliche Informationen über den Benutzer zu erhalten, wie z. B. seinen vollständigen Namen, seine E-Mail-Adresse oder sein Profilbild. Der Benutzerinfo-Endpunkt wird typischerweise aufgerufen, nachdem die Client-Anwendung ein Zugangstoken vom Token-Endpunkt erhalten hat.

Logto bietet auch ein profileMap-Feld, mit dem Benutzer die Zuordnung von den Profilen der sozialen Anbieter, die normalerweise nicht standardisiert sind, anpassen können. Die Schlüssel sind Logtos standardisierte Benutzerprofil-Feldnamen und die entsprechenden Werte sollten die Feldnamen der sozialen Profile sein. In der aktuellen Phase interessiert sich Logto nur für 'id', 'name', 'avatar', 'email' und 'phone' aus dem sozialen Profil, wobei nur 'id' erforderlich ist und die anderen optionale Felder sind.

responseType und grantType können NUR feste Werte mit dem Authorization Code Grant-Typ sein, daher machen wir sie optional und Standardwerte werden automatisch ausgefüllt.

Zum Beispiel kannst du Google Benutzerprofilantwort finden und daher sollte sein profileMap so aussehen:

{
  "id": "sub",
  "avatar": "picture"
}

hinweis:

Wir haben einen OPTIONALEN customConfig-Schlüssel bereitgestellt, um deine angepassten Parameter zu platzieren. Jeder soziale Identitätsanbieter könnte seine eigene Variante des OAuth-Standardprotokolls haben. Wenn dein gewünschter sozialer Identitätsanbieter strikt am OAuth-Standardprotokoll festhält, musst du dich nicht um customConfig kümmern.

Konfigurationstypen

Name	Typ	Erforderlich
authorizationEndpoint	string	true
userInfoEndpoint	string	true
clientId	string	true
clientSecret	string	true
tokenEndpointResponseType	enum	false
responseType	string	false
grantType	string	false
tokenEndpoint	string	false
scope	string	false
customConfig	Record<string, string>	false
profileMap	ProfileMap	false

ProfileMap-Felder	Typ	Erforderlich	Standardwert
id	string	false	id
name	string	false	name
avatar	string	false	avatar
email	string	false	email
phone	string	false	phone

Referenz

Das OAuth 2.0 Autorisierungsframework