Soziale Anmeldung mit OAuth 2.0-Protokoll einrichten

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

tipp

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 OAuth-Connector ermöglicht Logto die 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, was 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 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 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 um 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 gilt als vertrauliche Information 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" darauf hinweisen, 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 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 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 User-Info-Endpunkt wird typischerweise aufgerufen, nachdem die Client-Anwendung ein Zugangstoken vom Token-Endpunkt erhalten hat.

Logto bietet auch ein profileMap-Feld, das Benutzer anpassen können, um die Zuordnung von den Profilen der sozialen Anbieter, die normalerweise nicht standardisiert sind, zu ermöglichen. 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 benutzerdefinierten 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 Autorisierungs-Framework