Logto ist eine Auth0-Alternative, die für moderne Apps und SaaS-Produkte entwickelt wurde. Es bietet sowohl Cloud als auch Open-Source Dienste, um dir zu helfen, dein Identity and Management (IAM) System schnell zu starten. Genieße Authentifizierung, Autorisierung und Multi-Tenant-Management alles in einem.
Wir empfehlen, mit einem kostenlosen Entwicklungsmieter auf Logto Cloud zu beginnen. Dies ermöglicht es dir, alle Funktionen einfach zu erkunden.
In diesem Artikel werden wir die Schritte durchgehen, um schnell die SAML Anmeldeerfahrung (Benutzerauthentifizierung) mit React und Logto aufzubauen.
Voraussetzungen
- Eine laufende Logto-Instanz. Sieh dir die Einführungsseite an, um loszulegen.
- Grundkenntnisse in React.
- Ein nutzbares SAML Konto.
Eine Anwendung in Logto erstellen
Logto basiert auf OpenID Connect (OIDC) Authentifizierung und OAuth 2.0 Autorisierung. Es unterstützt föderiertes Identitätsmanagement über mehrere Anwendungen hinweg, was allgemein als Single Sign-On (SSO) bezeichnet wird.
Um deine Single Page App Anwendung zu erstellen, folge einfach diesen Schritten:
- Öffne die Logto Console. Klicke im Abschnitt "Erste Schritte" auf den Link "Alle anzeigen", um die Liste der Anwendungs-Frameworks zu öffnen. Alternativ kannst du zu Logto Console > Applications navigieren und auf die Schaltfläche "Anwendung erstellen" klicken.
- Klicke im sich öffnenden Modal auf den Abschnitt "Single Page App" oder filtere alle verfügbaren "Single Page App" Frameworks mit den Schnellfilter-Checkboxen auf der linken Seite. Klicke auf die "React" Framework-Karte, um mit der Erstellung deiner Anwendung zu beginnen.
- Gib den Anwendungsnamen ein, z. B. "Buchladen", und klicke auf "Anwendung erstellen".
🎉 Ta-da! Du hast gerade deine erste Anwendung in Logto erstellt. Du wirst eine Glückwunschseite sehen, die einen detaillierten Integrationsleitfaden enthält. Folge dem Leitfaden, um zu sehen, wie die Erfahrung in deiner Anwendung sein wird.
React SDK integrieren
- Das Beispielprojekt ist in unserem SDK-Repository verfügbar.
- Das Tutorial-Video ist auf unserem YouTube-Kanal verfügbar.
Installation
Installiere das Logto SDK über deinen bevorzugten Paketmanager:
- npm
- pnpm
- yarn
npm i @logto/react
pnpm add @logto/react
yarn add @logto/react
LogtoClient initialisieren
Importiere und verwende LogtoProvider
, um deiner App einen Logto-Kontext bereitzustellen:
import { LogtoProvider, LogtoConfig } from '@logto/react';
const config: LogtoConfig = {
endpoint: '<your-logto-endpoint>', // Z.B. http://localhost:3001
appId: '<your-application-id>',
};
const App = () => (
<LogtoProvider config={config}>
<YourAppContent />
</LogtoProvider>
);
Konfigurieren von Redirect-URIs
Bevor wir in die Details eintauchen, hier ein kurzer Überblick über die Endbenutzererfahrung. Der Anmeldeprozess kann wie folgt vereinfacht werden:
- Deine App ruft die Anmeldemethode auf.
- Der Benutzer wird zur Logto-Anmeldeseite umgeleitet. Bei nativen Apps wird der Systembrowser geöffnet.
- Der Benutzer meldet sich an und wird zurück zu deiner App umgeleitet (konfiguriert als die Redirect-URI).
Bezüglich der umleitungsbasierten Anmeldung
- Dieser Authentifizierungsprozess folgt dem OpenID Connect (OIDC) Protokoll, und Logto erzwingt strenge Sicherheitsmaßnahmen, um die Benutzeranmeldung zu schützen.
- Wenn du mehrere Apps hast, kannst du denselben Identitätsanbieter (Logto) verwenden. Sobald sich der Benutzer bei einer App anmeldet, wird Logto den Anmeldeprozess automatisch abschließen, wenn der Benutzer auf eine andere App zugreift.
Um mehr über die Gründe und Vorteile der umleitungsbasierten Anmeldung zu erfahren, siehe Logto-Anmeldeerfahrung erklärt.
In den folgenden Code-Snippets gehen wir davon aus, dass deine App unter http://localhost:3000/
läuft.
Redirect-URIs konfigurieren
Wechsle zur Anwendungsdetailseite der Logto-Konsole. Füge eine Redirect-URI http://localhost:3000/callback
hinzu.
Genau wie beim Anmelden sollten Benutzer zu Logto weitergeleitet werden, um sich von der gemeinsamen Sitzung abzumelden. Sobald dies abgeschlossen ist, wäre es ideal, den Benutzer zurück zu deiner Website zu leiten. Füge zum Beispiel http://localhost:3000/
als Redirect-URI nach dem Abmelden hinzu.
Klicke dann auf "Speichern", um die Änderungen zu speichern.
Redirect behandeln
Da wir http://localhost:3000/callback
als Redirect-URI verwenden, müssen wir diese nun ordnungsgemäß behandeln.
Erstellen wir zuerst eine Callback-Seite:
import { useHandleSignInCallback } from '@logto/react';
const Callback = () => {
const { isLoading } = useHandleSignInCallback(() => {
// Etwas tun, wenn fertig, z.B. zur Startseite umleiten
});
// Wenn es in Bearbeitung ist
if (isLoading) {
return <div>Weiterleiten...</div>;
}
return null;
};
Füge schließlich den folgenden Code ein, um eine /callback
-Route zu erstellen, die KEINE Authentifizierung erfordert:
// Angenommen, react-router
<Route path="/callback" element={<Callback />} />
Implementierung von Anmeldung und Abmeldung
Wir bieten zwei Hooks useHandleSignInCallback()
und useLogto()
, die dir helfen können, den Authentifizierungsfluss einfach zu verwalten.
Bevor du .signIn()
aufrufst, stelle sicher, dass du die Redirect-URI im Admin Console korrekt konfiguriert hast.
import { useLogto } from '@logto/react';
const Home = () => {
const { signIn, signOut, isAuthenticated } = useLogto();
return isAuthenticated ? (
<button onClick={signOut}>Abmelden</button>
) : (
<button onClick={() => signIn('http://localhost:3000/callback')}>Anmelden</button>
);
};
Das Aufrufen von .signOut()
wird alle Logto-Daten im Speicher und im localStorage löschen, falls sie vorhanden sind.
Checkpoint: Teste deine Anwendung
Jetzt kannst du deine Anwendung testen:
- Starte deine Anwendung, du wirst den Anmeldebutton sehen.
- Klicke auf den Anmeldebutton, das SDK wird den Anmeldeprozess initiieren und dich zur Logto-Anmeldeseite weiterleiten.
- Nachdem du dich angemeldet hast, wirst du zurück zu deiner Anwendung geleitet und siehst den Abmeldebutton.
- Klicke auf den Abmeldebutton, um den Token-Speicher zu leeren und dich abzumelden.
SAML Connector hinzufügen
Um eine schnelle Anmeldung zu ermöglichen und die Benutzerkonversion zu verbessern, verbinde dich mit React als Identitätsanbieter (IdP). Der Logto Social Connector hilft dir, diese Verbindung in wenigen Minuten herzustellen, indem er mehrere Parameter-Eingaben ermöglicht.
Um einen Social Connector hinzuzufügen, folge einfach diesen Schritten:
- Navigiere zu Console > Connectors > Social Connectors.
- Klicke auf "Add social connector" und wähle "SAML".
- Folge der README-Anleitung und fülle die erforderlichen Felder aus und passe die Einstellungen an.
Wenn du der In-Place Connector-Anleitung folgst, kannst du den nächsten Abschnitt überspringen.
Standard SAML-App einrichten
Konto des sozialen IdP erstellen und SAML-Anwendung registrieren (IdP)
Lassen Sie uns die Konfigurationen des SAML-Connectors durchgehen.
Bevor wir beginnen, können Sie zu einem sozialen Identitätsanbieter gehen, der das SAML-Protokoll unterstützt, und Ihr eigenes Konto erstellen. Okta, OneLogin, Salesforce und einige andere Plattformen unterstützen Authentifizierung basierend auf dem SAML-Protokoll.
Wenn Ihr IdP die Verschlüsselung der SAML-Assertion und den Empfang von signierten Authentifizierungsanfragen vorschreibt, sollten Sie Ihren privaten Schlüssel und das entsprechende Zertifikat mit dem RSA-Algorithmus generieren. Bewahren Sie den privaten Schlüssel für Ihre SP-Nutzung auf und laden Sie das Zertifikat zum IdP hoch.
Sie müssen auch die ACS (Assertion Consumer Service) URL als ${your_logto_origin}/api/authn/saml/${connector_id}
konfigurieren, um die SAML-Assertion des IdP zu verarbeiten. Ihren connectorId
finden Sie auf der Detailseite des SAML-Connectors in der Logto Admin-Konsole.
Nach dem aktuellen Design von Logto unterstützen wir nur Redirect-Binding für das Senden von Authentifizierungsanfragen und POST-Binding für den Empfang von SAML-Assertionen. Obwohl das nicht besonders cool klingt, glauben wir, dass das aktuelle Design die meisten Ihrer Anwendungsfälle abdecken kann. Wenn Sie Probleme haben, zögern Sie nicht, uns zu kontaktieren!
SAML-Connector konfigurieren (SP)
In diesem Abschnitt werden wir jedes Attribut im Detail vorstellen.
entityID Erforderlich
entityID
(d. h. issuer
) ist der Entitätsbezeichner. Es wird verwendet, um Ihre Entität (SAML SP-Entität) zu identifizieren und die Gleichwertigkeit in jeder SAML-Anfrage/-Antwort abzugleichen.
signInEndpoint Erforderlich
Der Endpunkt des IdP, an den Sie SAML-Authentifizierungsanfragen senden. Normalerweise finden Sie diesen Wert auf der Detailseite des IdP (d. h. SSO URL
oder Login URL
des IdP).
x509Certificate Erforderlich
Das x509-Zertifikat, das aus dem privaten Schlüssel des IdP generiert wurde. Der IdP sollte diesen Wert verfügbar haben.
Der Inhalt des Zertifikats beginnt mit dem Header -----BEGIN CERTIFICATE-----
und endet mit dem Abschluss -----END CERTIFICATE-----
.
idpMetadataXml Erforderlich
Dieses Feld wird verwendet, um Inhalte aus Ihrer IdP-Metadaten-XML-Datei zu platzieren.
Der von uns verwendete XML-Parser unterstützt keine benutzerdefinierten Namespaces. Wenn die IdP-Metadaten mit einem Namespace versehen sind, sollten Sie diese manuell entfernen. Für den Namespace der XML-Datei siehe Referenz.
assertionConsumerServiceUrl Erforderlich
Die Assertion Consumer Service (ACS) URL ist der Endpunkt des SP, um die SAML-Assertion POST-Anfragen des IdP zu empfangen. Wie im vorherigen Teil erwähnt, wird sie normalerweise in den IdP-Einstellungen konfiguriert, aber einige IdP erhalten diesen Wert aus SAML-Authentifizierungsanfragen, daher fügen wir diesen Wert auch als ERFORDERLICHES Feld hinzu. Sein Wert sollte wie ${your_logto_origin}/api/authn/saml/${connector_id}
aussehen.
signAuthnRequest
Der boolesche Wert, der steuert, ob die SAML-Authentifizierungsanfrage signiert werden soll, dessen Standardwert false
ist.
encryptAssertion
encryptAssertion
ist ein boolescher Wert, der angibt, ob der IdP die SAML-Assertion verschlüsseln wird, mit dem Standardwert false
.
Die Attribute signAuthnRequest
und encryptAssertion
sollten mit den entsprechenden Parametern der IdP-Einstellung übereinstimmen, andernfalls wird ein Fehler angezeigt, der zeigt, dass die Konfiguration nicht übereinstimmt.
Alle SAML-Antworten müssen signiert sein.
requestSignatureAlgorithm
Dies sollte mit den Signaturalgorithmen des IdP übereinstimmen, damit Logto die Signatur der SAML-Assertion überprüfen kann. Sein Wert sollte entweder http://www.w3.org/2000/09/xmldsig#rsa-sha1
, http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
oder http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
sein und der Standardwert ist http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
.
messageSigningOrder
messageSigningOrder
gibt die Signier- und Verschlüsselungsreihenfolge des IdP an, sein Wert sollte entweder sign-then-encrypt
oder encrypt-then-sign
sein und der Standardwert ist sign-then-encrypt
.
privateKey und privateKeyPass
privateKey
ist ein OPTIONALER Wert und wird benötigt, wenn signAuthnRequest
true
ist.
privateKeyPass
ist das Passwort, das Sie beim Erstellen von privateKey
festgelegt haben, erforderlich, wenn nötig.
Wenn signAuthnRequest
true
ist, wird das entsprechende Zertifikat, das aus privateKey
generiert wurde, vom IdP benötigt, um die Signatur zu überprüfen.
encPrivateKey und encPrivateKeyPass
encPrivateKey
ist ein OPTIONALER Wert und wird benötigt, wenn encryptAssertion
true
ist.
encPrivateKeyPass
ist das Passwort, das Sie beim Erstellen von encPrivateKey
festgelegt haben, erforderlich, wenn nötig.
Wenn encryptAssertion
true
ist, wird das entsprechende Zertifikat, das aus encPrivateKey
generiert wurde, vom IdP benötigt, um die SAML-Assertion zu verschlüsseln.
Für die Generierung von Schlüsseln und Zertifikaten ist openssl
ein hervorragendes Werkzeug. Hier ist eine Beispiel-Befehlszeile, die hilfreich sein könnte:
openssl genrsa -passout pass:${privateKeyPassword} -out ${encryptPrivateKeyFilename}.pem 4096
openssl req -new -x509 -key ${encryptPrivateKeyFilename}.pem -out ${encryptionCertificateFilename}.cer -days 3650
privateKey
- und encPrivateKey
-Dateien müssen im pkcs1
-Schema als PEM-String codiert sein, was bedeutet, dass die privaten Schlüsseldateien mit -----BEGIN RSA PRIVATE KEY-----
beginnen und mit -----END RSA PRIVATE KEY-----
enden sollten.
nameIDFormat
nameIDFormat
ist ein OPTIONALES Attribut, das das Name-ID-Format deklariert, das antworten würde. Der Wert kann unter urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
, urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
, urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
, urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
und urn:oasis:names:tc:SAML:2.0:nameid-format:transient
sein, und der Standardwert ist urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified
.
timeout
timeout
ist die Zeitdifferenz für die Zeitvalidierung, da die Zeit zwischen Ihrer SP-Entität und der IdP-Entität unterschiedlich sein könnte und die Netzwerkverbindung auch einige Verzögerungen mit sich bringen kann. Die Einheit ist in Millisekunden, und der Standardwert ist 5000 (d. h. 5s).
profileMap
Logto bietet auch ein profileMap
-Feld, mit dem Benutzer die Zuordnung von den sozialen Anbieterprofilen, die normalerweise nicht standardisiert sind, anpassen können. Jeder profileMap
-Schlüssel ist der standardmäßige Benutzerprofil-Feldname von Logto und der entsprechende Wert sollte der soziale Profilfeldname sein. In der aktuellen Phase interessiert sich Logto nur für 'id', 'name', 'avatar', 'email' und 'phone' aus dem sozialen Profil, nur 'id' ist ERFORDERLICH und andere sind optionale Felder.
Konfigurationstypen
Name | Typ | Erforderlich | Standardwert |
---|---|---|---|
signInEndpoint | string | true | |
x509certificate | string | true | |
idpMetadataXml | string | true | |
entityID | string | true | |
assertionConsumerServiceUrl | string | true | |
messageSigningOrder | encrypt-then-sign | sign-then-encrypt | false | sign-then-encrypt |
requestSignatureAlgorithm | http://www.w3.org/2000/09/xmldsig#rsa-sha1 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 | http://www.w3.org/2001/04/xmldsig-more#rsa-sha512 | false | http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 |
signAuthnRequest | boolean | false | false |
encryptAssertion | boolean | false | false |
privateKey | string | false | |
privateKeyPass | string | false | |
nameIDFormat | urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress | urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName | urn:oasis:names:tc:SAML:2.0:nameid-format:persistent | urn:oasis:names:tc:SAML:2.0:nameid-format:transient | false | urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified |
timeout | number | false | 5000 |
profileMap | ProfileMap | false |
ProfileMap-Felder | Typ | Erforderlich | Standardwert |
---|---|---|---|
id | string | false | id |
name | string | false | name |
avatar | string | false | avatar |
string | false | ||
phone | string | false | phone |
Referenz
- Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0
- samlify - Hochgradig konfigurierbare Node.js SAML 2.0 Bibliothek für Single Sign On
Konfiguration speichern
Überprüfe, ob du alle notwendigen Werte im Logto Connector-Konfigurationsbereich ausgefüllt hast. Klicke auf "Speichern und Fertig" (oder "Änderungen speichern") und der SAML Connector sollte jetzt verfügbar sein.
SAML Connector in der Anmeldeerfahrung aktivieren
Sobald du einen sozialen Connector erfolgreich erstellt hast, kannst du ihn als "Weiter mit SAML"-Button in der Anmeldeerfahrung aktivieren.
- Navigiere zu Konsole > Anmeldeerfahrung > Registrierung und Anmeldung.
- (Optional) Wähle "Nicht zutreffend" für das Registrierungskennzeichen, wenn du nur die soziale Anmeldung benötigst.
- Füge den konfigurierten SAML Connector zum Abschnitt "Soziale Anmeldung" hinzu.
Testen und Validieren
Kehre zu deiner React-App zurück. Du solltest dich jetzt mit SAML anmelden können. Viel Spaß!
Weiterführende Lektüre
Endbenutzerflüsse: Logto bietet sofort einsatzbereite Authentifizierungsflüsse, einschließlich Multi-Faktor-Authentifizierung (MFA) und Enterprise SSO, zusammen mit leistungsstarken APIs für die flexible Implementierung von Kontoeinstellungen, Sicherheitsüberprüfung und Multi-Tenant-Erfahrung.
Autorisierung: Autorisierung (Authorization) definiert die Aktionen, die ein Benutzer ausführen kann, oder die Ressourcen, auf die er nach der Authentifizierung zugreifen kann. Erfahre, wie du deine API für native und Single-Page-Anwendungen schützen und rollenbasierte Zugangskontrolle (RBAC) implementieren kannst.
Organisationen: Besonders effektiv in Multi-Tenant-SaaS- und B2B-Anwendungen, ermöglicht die Organisationsfunktion die Erstellung von Mandanten, das Mitgliedermanagement, organisationsweite RBAC und Just-in-Time-Bereitstellung.
Kunden-IAM-Serie: Unsere Blogserie über Customer (oder Consumer) Identity and Access Management, von den Grundlagen bis zu fortgeschrittenen Themen und darüber hinaus.