Authentifizierung zu deiner Webflow-Anwendung hinzufügen

Dieser Leitfaden zeigt dir, wie du Logto in deine Webflow-Seiten integrieren kannst.

tipp:

Das Beispielprojekt ist verfügbar unter Webflow-Projektvorschau.

Voraussetzungen

Die Integration von Logto mit Webflow erfordert die "Custom code"-Funktion von Webflow, die mindestens den "Basic"-Plan erfordert.
Eine Webflow-Seite, entweder eine bestehende Seite verwenden oder eine neue erstellen.

Integration

Logto-Anbieter initialisieren

hinweis:

In den folgenden Schritten gehen wir davon aus, dass deine Webflow-Seite unter https://your-awesome-site.webflow.io läuft.

In diesem Schritt fügen wir globalen benutzerdefinierten Code zu deiner Webflow-Seite hinzu. Da NPM in Webflow nicht unterstützt wird, verwenden wir den jsdelivr.com CDN-Dienst, um das Logto SDK zu importieren.

Öffne die Seite "Site-Einstellungen" und navigiere zum Abschnitt "Benutzerdefinierter Code". Füge den folgenden Code in den Abschnitt "Head-Code" ein.

<script type="module">
  // Importiere das \`@logto/browser\` SDK von der jsdelivr CDN
  import LogtoClient from 'https://esm.run/@logto/browser';

  // Weise die \`logtoClient\` Instanz dem Fensterobjekt zu,
  // um die globale Nutzung auf anderen Seiten zu ermöglichen
  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>', // z.B. http://localhost:3001
    appId: '<your-application-id>',
  });
</script>

Bevor wir ins Detail gehen, hier ein schneller Überblick über die Endbenutzererfahrung. Der Anmeldeprozess lässt sich wie folgt vereinfachen:

Deine App löst die Anmeldemethode aus.
Der Benutzer wird auf die 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 Redirect-URI).

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.

Wechseln wir zur Seite "Anwendungsdetails" der Logto-Konsole. Füge eine Redirect-URI https://your-awesome-site.webflow.io/callback hinzu und klicke auf "Änderungen speichern".

Kehre zu deinem Webflow-Designer zurück, ziehe einen "Anmelden"-Button auf die Startseite und weise ihm eine ID „sign-in“ zu, um später mit getElementById() darauf zuzugreifen.

<script type="module">
  const signInButton = document.getElementById('sign-in');
  const onClickSignIn = () => logtoClient.signIn('https://your-awesome-site.webflow.io/callback');
  signInButton.addEventListener('click', onClickSignIn);
</script>

Umleitung behandeln

Wir sind fast am Ziel! Im letzten Schritt verwenden wir https://your-awesome-site.webflow.io/callback als Redirect-URI, und jetzt müssen wir sie richtig handhaben.

Erstellen wir zuerst eine "Callback"-Seite in Webflow und fügen einfach etwas statischen Text "Weiterleiten..." darauf ein. Füge dann den folgenden seitenbezogenen benutzerdefinierten Code zur "Callback"-Seite hinzu.

<script type="module">
  (async () => {
    // Sign-In Callback-Logik durch Aufruf der SDK-Methode behandeln
    await logtoClient.handleSignInCallback(window.location.href);

    // Zurück zur Startseite weiterleiten, wenn die Verarbeitung abgeschlossen ist
    window.location.assign('https://your-awesome-site.webflow.io');
  })();
</script>

Abmeldung implementieren

Das Aufrufen von .signOut() wird alle Logto-Daten im Speicher und im localStorage löschen, falls sie vorhanden sind.

Nach dem Abmelden ist es ideal, deinen Benutzer zurück zu deiner Website zu leiten. Füge https://your-awesome-site.webflow.io als eine der Post Sign-out URIs in der Admin-Konsole hinzu (erscheint unter Redirect URIs) und verwende die URL als Parameter beim Aufrufen von .signOut().

Einen Abmelde-Button implementieren

Kehre zum Webflow-Designer zurück und füge einen „Abmelden“-Button auf deiner Startseite hinzu. Weise dem Button ähnlich eine ID „sign-out“ zu und füge den folgenden Code zum benutzerdefinierten Code auf Seitenebene hinzu.

const signOutButton = document.getElementById('sign-out');
const onClickSignOut = () => logtoClient.signOut('https://your-awesome-site.webflow.io');
signOutButton.addEventListener('click', onClickSignOut);

Authentifizierungsstatus verwalten

Im Logto SDK können wir im Allgemeinen die Methode logtoClient.isAuthenticated() verwenden, um den Authentifizierungsstatus zu überprüfen. Wenn der Benutzer angemeldet ist, wird der Wert true sein; andernfalls wird er false sein.

Auf deiner Webflow-Seite kannst du diese Methode auch verwenden, um die Anmelde- und Abmeldebuttons programmatisch anzuzeigen oder auszublenden. Wende den folgenden benutzerdefinierten Code an, um die CSS der Buttons entsprechend anzupassen.

const isAuthenticated = await logtoClient.isAuthenticated();

signInButton.style.display = isAuthenticated ? 'none' : 'block';
signOutButton.style.display = isAuthenticated ? 'block' : 'none';

Checkpoint: Teste deine Webflow-Seite

Teste nun deine Seite:

Stelle deine Seite bereit und besuche die URL deiner Seite, der Anmeldebutton sollte sichtbar sein.
Klicke auf den Anmeldebutton, das SDK wird den Anmeldeprozess initiieren und dich zur Logto-Anmeldeseite weiterleiten.
Nach der Anmeldung wirst du zurück zu deiner Seite geleitet und siehst den Benutzernamen und den Abmeldebutton.
Klicke auf den Abmeldebutton, um dich abzumelden.

Benutzerinformationen abrufen

Du kannst diese Logto-Methoden verwenden, um Benutzerinformationen programmgesteuert abzurufen:

getIdTokenClaims: Benutzerinformationen durch Dekodieren des lokalen ID-Tokens abrufen. Einige Ansprüche (Claims) sind möglicherweise nicht verfügbar.
fetchUserInfo: Benutzerinformationen durch Senden einer Anfrage an den userinfo endpoint abrufen.

Es ist wichtig zu beachten, dass die Benutzerinformationsansprüche, die abgerufen werden können, von den Berechtigungen (Scopes) abhängen, die der Benutzer während der Anmeldung verwendet hat. In Anbetracht der Leistung und der Datengröße kann das ID-Token möglicherweise nicht alle Benutzeransprüche enthalten; einige Benutzeransprüche sind nur im userinfo endpoint verfügbar (siehe die zugehörige Liste unten).

Logto verwendet die OIDC Scopes- und Claims-Konventionen, um die Berechtigungen (Scopes) und Ansprüche (Claims) für das Abrufen von Benutzerinformationen aus dem ID-Token und dem OIDC userinfo-Endpunkt zu definieren. Sowohl „Berechtigung (Scope)“ als auch „Anspruch (Claim)“ sind Begriffe aus den OAuth 2.0- und OpenID Connect (OIDC)-Spezifikationen.

Für Standard-OIDC-Ansprüche wird die Aufnahme in das ID-Token strikt durch die angeforderten Berechtigungen bestimmt. Erweiterte Ansprüche (wie custom_data und organizations) können zusätzlich so konfiguriert werden, dass sie im ID-Token über die Custom ID token-Einstellungen erscheinen.

Kurz gesagt: Wenn du eine Berechtigung (Scope) anforderst, erhältst du die entsprechenden Ansprüche (Claims) in den Benutzerinformationen. Zum Beispiel: Wenn du die `email`-Berechtigung anforderst, erhältst du die `email`- und `email_verified`-Daten des Benutzers.

Standardmäßig fordert das Logto SDK immer drei Berechtigungen an: `openid`, `profile` und `offline_access`. Es gibt keine Möglichkeit, diese Standardberechtigungen zu entfernen. Du kannst jedoch beim Konfigurieren von Logto weitere Berechtigungen hinzufügen:

<script type="module">
  // Import \`@logto/browser\` SDK von der jsdelivr CDN
  import LogtoClient from 'https://esm.run/@logto/browser';

  // Weisen Sie die \`logtoClient\`-Instanz dem Fensterobjekt zu,
  // um die globale Nutzung auf anderen Seiten zu ermöglichen
  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>', // z.B. http://localhost:3001
    appId: '<your-application-id>',
    scopes: [
      UserScope.Email,
      UserScope.Phone,
      UserScope.CustomData,
      UserScope.Identities,
      UserScope.Organizations,
    ],
  });
</script>

Hier ist die Liste der unterstützten Berechtigungen (Scopes) und der entsprechenden Ansprüche (Claims):

Standard OIDC-Berechtigungen (Scopes)

openid (Standard)

Claim-Name	Typ	Beschreibung
sub	`string`	Der eindeutige Identifikator des Benutzers

profile (Standard)

Claim-Name	Typ	Beschreibung
name	`string`	Der vollständige Name des Benutzers
username	`string`	Der Benutzername des Benutzers
picture	`string`	URL zum Profilbild des Endbenutzers. Diese URL MUSS auf eine Bilddatei (z. B. PNG, JPEG oder GIF) verweisen, nicht auf eine Webseite mit einem Bild. Beachte, dass diese URL speziell auf ein Profilfoto des Endbenutzers verweisen SOLLTE, das zur Darstellung des Endbenutzers geeignet ist, und nicht auf ein beliebiges vom Endbenutzer aufgenommenes Foto.
created_at	`number`	Zeitpunkt, zu dem der Endbenutzer erstellt wurde. Die Zeit wird als Anzahl der Millisekunden seit der Unix-Epoche (1970-01-01T00:00:00Z) dargestellt.
updated_at	`number`	Zeitpunkt, zu dem die Informationen des Endbenutzers zuletzt aktualisiert wurden. Die Zeit wird als Anzahl der Millisekunden seit der Unix-Epoche (1970-01-01T00:00:00Z) dargestellt.

Weitere Standard-Ansprüche (Claims) wie family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo und locale werden ebenfalls im profile-Scope enthalten sein, ohne dass der userinfo-Endpunkt angefragt werden muss. Ein Unterschied zu den oben genannten Claims besteht darin, dass diese Claims nur zurückgegeben werden, wenn ihre Werte nicht leer sind, während die oben genannten Claims null zurückgeben, wenn die Werte leer sind.

hinweis:

Im Gegensatz zu den Standard-Claims verwenden die Claims created_at und updated_at Millisekunden anstelle von Sekunden.

email

Claim-Name	Typ	Beschreibung
email	`string`	Die E-Mail-Adresse des Benutzers
email_verified	`boolean`	Ob die E-Mail-Adresse verifiziert wurde

phone

Claim-Name	Typ	Beschreibung
phone_number	`string`	Die Telefonnummer des Benutzers
phone_number_verified	`boolean`	Ob die Telefonnummer verifiziert wurde

address

Bitte siehe die OpenID Connect Core 1.0 für Details zum Address-Claim.

info:

Scopes, die mit (Standard) gekennzeichnet sind, werden immer vom Logto SDK angefordert. Claims unter den Standard-OIDC-Scopes sind immer im ID-Token enthalten, wenn der entsprechende Scope angefordert wird — sie können nicht deaktiviert werden.

Erweiterte Berechtigungen (Scopes)

Die folgenden Scopes sind von Logto erweitert und liefern Claims über den userinfo-Endpunkt. Diese Claims können auch so konfiguriert werden, dass sie direkt im ID-Token enthalten sind, über Konsole > Benutzerdefiniertes JWT. Siehe Benutzerdefiniertes ID-Token für weitere Details.

custom_data

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
custom_data	`object`	Die benutzerdefinierten Daten des Benutzers

identities

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
identities	`object`	Die verknüpften Identitäten des Benutzers
sso_identities	`array`	Die verknüpften SSO-Identitäten des Benutzers

roles

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
roles	`string[]`	Die Rollen (Roles) des Benutzers	✅

urn:logto:scope:organizations

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
organizations	`string[]`	Die Organisations-IDs, denen der Benutzer angehört	✅
organization_data	`object[]`	Die Organisationsdaten, denen der Benutzer angehört

hinweis:

Diese Organisations-Claims können auch über den userinfo-Endpunkt abgerufen werden, wenn ein opaker Token verwendet wird. Allerdings können opake Tokens nicht als Organisationstoken für den Zugriff auf organisationsspezifische Ressourcen verwendet werden. Siehe Opaker Token und Organisationen für weitere Details.

urn:logto:scope:organization_roles

Claim-Name	Typ	Beschreibung	Standardmäßig im ID-Token enthalten
organization_roles	`string[]`	Die Organisationsrollen, denen der Benutzer angehört, im Format `<organization_id>:<role_name>`	✅

API-Ressourcen

Wir empfehlen, zuerst 🔐 Rollenbasierte Zugangskontrolle (RBAC) zu lesen, um die grundlegenden Konzepte von Logto RBAC zu verstehen und wie man API-Ressourcen richtig einrichtet.

Logto-Client konfigurieren

Sobald du die API-Ressourcen eingerichtet hast, kannst du sie bei der Konfiguration von Logto in deiner App hinzufügen:

<script type="module">
  // Import \`@logto/browser\` SDK von der jsdelivr CDN
  import LogtoClient from 'https://esm.run/@logto/browser';

  // Weisen Sie die \`logtoClient\`-Instanz dem Fensterobjekt zu,
  // um die globale Nutzung auf anderen Seiten zu ermöglichen
  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>', // Z.B. http://localhost:3001
    appId: '<your-application-id>',
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // API-Ressourcen hinzufügen
  });
</script>

Jede API-Ressource hat ihre eigenen Berechtigungen (Berechtigungen).

Zum Beispiel hat die Ressource https://shopping.your-app.com/api die Berechtigungen shopping:read und shopping:write, und die Ressource https://store.your-app.com/api hat die Berechtigungen store:read und store:write.

Um diese Berechtigungen anzufordern, kannst du sie bei der Konfiguration von Logto in deiner App hinzufügen:

<script type="module">
  // Import \`@logto/browser\` SDK from the jsdelivr CDN
  import LogtoClient from 'https://esm.run/@logto/browser';

  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>',
    appId: '<your-application-id>',
    scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
  });
</script>

Du wirst bemerken, dass Berechtigungen separat von API-Ressourcen definiert sind. Dies liegt daran, dass Resource Indicators for OAuth 2.0 spezifiziert, dass die endgültigen Berechtigungen für die Anfrage das kartesische Produkt aller Berechtigungen bei allen Zielservices sein werden.

Somit können im obigen Fall die Berechtigungen aus der Definition in Logto vereinfacht werden, beide API-Ressourcen können read und write Berechtigungen ohne Präfix haben. Dann, in der Logto-Konfiguration:

<script type="module">
  // Import \`@logto/browser\` SDK von der jsdelivr CDN
  import LogtoClient from 'https://esm.run/@logto/browser';

  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>',
    appId: '<your-application-id>',
    scopes: ['read', 'write'],
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
  });
</script>

Für jede API-Ressource wird sowohl read als auch write Berechtigungen angefordert.

hinweis:

Es ist in Ordnung, Berechtigungen anzufordern, die in den API-Ressourcen nicht definiert sind. Zum Beispiel kannst du die Berechtigung email anfordern, auch wenn die API-Ressourcen die Berechtigung email nicht verfügbar haben. Nicht verfügbare Berechtigungen werden sicher ignoriert.

Nach der erfolgreichen Anmeldung wird Logto die entsprechenden Berechtigungen an API-Ressourcen gemäß den Rollen des Benutzers ausstellen.

Zugangstoken für die API-Ressource abrufen

Um das Zugangstoken für eine spezifische API-Ressource abzurufen, kannst du die Methode getAccessToken verwenden:

const isAuthenticated = await logtoClient.isAuthenticated();

if (isAuthenticated) {
  (async () => {
    const token = await logtoClient.getAccessToken();
    console.log(token);
  })();
}

Diese Methode gibt ein JWT-Zugangstoken zurück, das verwendet werden kann, um auf die API-Ressource zuzugreifen, wenn der Benutzer die entsprechenden Berechtigungen hat. Wenn das aktuell zwischengespeicherte Zugangstoken abgelaufen ist, versucht diese Methode automatisch, ein Auffrischungstoken zu verwenden, um ein neues Zugangstoken zu erhalten.

Organisationstokens abrufen

Wenn Organisationen neu für dich sind, lies bitte 🏢 Organisationen (Multi-Tenancy), um loszulegen.

Du musst die Berechtigung UserScope.Organizations hinzufügen, wenn du den Logto-Client konfigurierst:

import LogtoClient, { UserScope } from 'https://esm.run/@logto/browser';

window.logtoClient = new LogtoClient({
  // ...other configs
  scopes: [UserScope.Organizations],
});

Sobald der Benutzer angemeldet ist, kannst du das Organisationstoken für den Benutzer abrufen:

import { UserScope } from 'https://esm.run/@logto/browser';

const isAuthenticated = await logtoClient.isAuthenticated();

(async () => {
  if (!isAuthenticated) {
    return;
  }
  const claims = await logtoClient.getIdTokenClaims();

  console.log('ID-Token-Ansprüche:', claims);
  console.log('Organisations-IDs:', claims.organizations);

  // Angenommen, es gibt mindestens eine Organisation, nehmen wir die erste
  const organizationId = claims.organizations[0];
  const token = await logtoClient.getOrganizationToken(organizationId);

  console.log('Organisations-Zugangstoken:', token);
})();

Weiterführende Lektüre

Endbenutzerflüsse: Authentifizierungsflüsse, Kontoflüsse und Organisationsflüsse Connectors konfigurieren Autorisierung (Authorization)

Voraussetzungen​

Integration​

Logto-Anbieter initialisieren​

Anmeldung implementieren​

Bezüglich der umleitungsbasierten Anmeldung​

Umleitungs-URI für die Anmeldung konfigurieren​

Anmeldebutton implementieren​

Umleitung behandeln​

Abmeldung implementieren​

Einen Abmelde-Button implementieren​

Authentifizierungsstatus verwalten​

Checkpoint: Teste deine Webflow-Seite​

Benutzerinformationen abrufen​

Standard OIDC-Berechtigungen (Scopes)​

Erweiterte Berechtigungen (Scopes)​

API-Ressourcen​

Logto-Client konfigurieren​

Zugangstoken für die API-Ressource abrufen​

Organisationstokens abrufen​

Weiterführende Lektüre​

Voraussetzungen

Integration

Logto-Anbieter initialisieren

Anmeldung implementieren

Bezüglich der umleitungsbasierten Anmeldung

Umleitungs-URI für die Anmeldung konfigurieren

Anmeldebutton implementieren

Umleitung behandeln

Abmeldung implementieren

Einen Abmelde-Button implementieren

Authentifizierungsstatus verwalten

Checkpoint: Teste deine Webflow-Seite

Benutzerinformationen abrufen

Standard OIDC-Berechtigungen (Scopes)

Erweiterte Berechtigungen (Scopes)

API-Ressourcen

Logto-Client konfigurieren

Zugangstoken für die API-Ressource abrufen

Organisationstokens abrufen

Weiterführende Lektüre