Ajoutez l’authentification à votre application Webflow

Ce guide vous montrera comment intégrer Logto dans vos sites Webflow.

astuce

Le projet d'exemple est disponible sur aperçu du projet Webflow.
Une démonstration en direct est déployée à l'adresse https://charless-trendy-site-f191c0.webflow.io/.

Prérequis

L'intégration de Logto avec Webflow nécessite la fonctionnalité "Custom code" de Webflow, qui requiert au moins le plan "Basic".
Un site Webflow, soit utiliser un site existant, soit en créer un nouveau.

Intégration

Initier le fournisseur Logto

remarque

Dans les étapes suivantes, nous supposons que votre site Webflow fonctionne sur https://your-awesome-site.webflow.io.

Dans cette étape, nous allons ajouter du code personnalisé au niveau global à votre site Webflow. Étant donné que NPM n'est pas pris en charge dans Webflow, nous utiliserons le service CDN jsdelivr.com pour importer le SDK Logto.

Ouvrez la page "Site settings" et accédez à la section "Custom code". Ajoutez le code suivant à la section "Head code".

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

  // Assigner l'instance \`logtoClient\` à l'objet window,
  // permettant une utilisation globale dans d'autres pages
  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>', // Par exemple, http://localhost:3001
    appId: '<your-application-id>',
  });
</script>

Implémenter la connexion

Avant de plonger dans les détails, voici un aperçu rapide de l'Expérience utilisateur. Le processus de connexion peut être simplifié comme suit :

Votre application lance la méthode de connexion.
L'utilisateur est redirigé vers la page de connexion Logto. Pour les applications natives, le navigateur système est ouvert.
L'utilisateur se connecte et est redirigé vers votre application (configurée comme l'URI de redirection).

Concernant la connexion basée sur la redirection

Ce processus d'authentification (Authentication) suit le protocole OpenID Connect (OIDC), et Logto applique des mesures de sécurité strictes pour protéger la connexion utilisateur.
Si vous avez plusieurs applications, vous pouvez utiliser le même fournisseur d’identité (Logto). Une fois que l'utilisateur se connecte à une application, Logto complétera automatiquement le processus de connexion lorsque l'utilisateur accède à une autre application.

Pour en savoir plus sur la logique et les avantages de la connexion basée sur la redirection, consultez Expérience de connexion Logto expliquée.

Configurer l'URI de redirection de connexion

Passons à la page des détails de l'application de Logto Console. Ajoutez une URI de redirection https://your-awesome-site.webflow.io/callback et cliquez sur "Enregistrer les modifications".

Implémenter un bouton de connexion

Retournez à votre concepteur Webflow, faites glisser et déposez un bouton "Sign in" sur la page d'accueil, et attribuez-lui un ID “sign-in” pour une référence ultérieure en utilisant getElementById().

<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>

Gérer la redirection

Nous y sommes presque ! Dans la dernière étape, nous utilisons https://your-awesome-site.webflow.io/callback comme URI de redirection, et maintenant nous devons le gérer correctement.

Tout d'abord, créons une page "Callback" dans Webflow, et mettons simplement un texte statique "Redirection..." dessus. Ensuite, ajoutez le code personnalisé suivant au niveau de la page "Callback".

<script type="module">
  (async () => {
    // Gérer la logique de rappel de connexion en appelant la méthode SDK
    await logtoClient.handleSignInCallback(window.location.href);

    // Rediriger vers la page d'accueil lorsque le traitement est terminé
    window.location.assign('https://your-awesome-site.webflow.io');
  })();
</script>

Implémenter la déconnexion

Appeler .signOut() effacera toutes les données Logto en mémoire et dans le localStorage si elles existent.

Après la déconnexion, il serait idéal de rediriger votre utilisateur vers votre site web. Ajoutons https://your-awesome-site.webflow.io comme l'une des URI de post-déconnexion dans la Console d'administration (affichées sous URI de redirection), et utilisons l'URL comme paramètre lors de l'appel de .signOut().

Implémenter un bouton de déconnexion

Retournez au concepteur Webflow, et ajoutez un bouton "Déconnexion" sur votre page d'accueil. De même, attribuez un ID "sign-out" au bouton, et ajoutez le code suivant au code personnalisé au niveau de la page.

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

Gérer le statut d'authentification

Dans le SDK Logto, nous pouvons généralement utiliser la méthode logtoClient.isAuthenticated() pour vérifier le statut d'authentification (Authentication). Si l'utilisateur est connecté, la valeur sera true; sinon, elle sera false.

Sur votre site Webflow, vous pouvez également l'utiliser pour afficher et masquer de manière programmatique les boutons de connexion et de déconnexion. Appliquez le code personnalisé suivant pour ajuster le CSS des boutons en conséquence.

const isAuthenticated = await logtoClient.isAuthenticated();

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

Point de contrôle : Testez votre site Webflow

Maintenant, testez votre site :

Déployez et visitez l'URL de votre site, le bouton de connexion devrait être visible.
Cliquez sur le bouton de connexion, le SDK initiera le processus de connexion, vous redirigeant vers la page de connexion Logto.
Après vous être connecté, vous serez redirigé vers votre site, voyant le nom d'utilisateur et le bouton de déconnexion.
Cliquez sur le bouton de déconnexion pour vous déconnecter.

Obtenir des informations sur l'utilisateur

Vous pouvez utiliser ces méthodes Logto pour récupérer des informations utilisateur de manière programmatique :

getIdTokenClaims : Obtenez des informations utilisateur en décodant le jeton d’identifiant (ID token) local. Certaines revendications peuvent ne pas être disponibles.
fetchUserInfo : Obtenez des informations utilisateur en envoyant une requête au point de terminaison userinfo.

Il est important de noter que les revendications d'informations utilisateur qui peuvent être récupérées dépendent des portées utilisées par l'utilisateur lors de la connexion, et en considérant les performances et la taille des données, le jeton d’identifiant (ID token) peut ne pas contenir toutes les revendications utilisateur, certaines revendications utilisateur ne sont disponibles que dans le point de terminaison userinfo (voir la liste associée ci-dessous).

Logto utilise les conventions de portées et revendications OIDC pour définir les Portées et Revendications pour récupérer les informations utilisateur à partir du Jeton d’identifiant et du point de terminaison OIDC userinfo. Les termes "Portée" et "Revendication" proviennent des spécifications OAuth 2.0 et OpenID Connect (OIDC).

En bref, lorsque vous demandez une Portée, vous obtiendrez les Revendications correspondantes dans les informations utilisateur. Par exemple, si vous demandez la portée `email`, vous obtiendrez les données `email` et `email_verified` de l'utilisateur.

Par défaut, le SDK Logto demandera toujours trois Portées : `openid`, `profile` et `offline_access`, et il n'est pas possible de supprimer ces Portées par défaut. Mais vous pouvez ajouter plus de Portées lors de la configuration de Logto :

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

  // Assigner l'instance \`logtoClient\` à l'objet window,
  // permettant une utilisation globale dans d'autres pages
  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>', // Par exemple http://localhost:3001
    appId: '<your-application-id>',
    scopes: [
      UserScope.Email,
      UserScope.Phone,
      UserScope.CustomData,
      UserScope.Identities,
      UserScope.Organizations,
    ],
  });
</script>

Voici la liste des Portées (Scopes) prises en charge et les Revendications (Claims) correspondantes :

openid

Nom de la revendication	Type	Description	Besoin d'userinfo ?
sub	`string`	L'identifiant unique de l'utilisateur	Non

profile

Nom de la revendication	Type	Description	Besoin d'userinfo ?
name	`string`	Le nom complet de l'utilisateur	Non
username	`string`	Le nom d'utilisateur de l'utilisateur	Non
picture	`string`	URL de la photo de profil de l'utilisateur final. Cette URL DOIT faire référence à un fichier image (par exemple, un fichier image PNG, JPEG ou GIF), plutôt qu'à une page Web contenant une image. Notez que cette URL DOIT spécifiquement référencer une photo de profil de l'utilisateur final adaptée à l'affichage lors de la description de l'utilisateur final, plutôt qu'une photo arbitraire prise par l'utilisateur final.	Non
created_at	`number`	Heure à laquelle l'utilisateur final a été créé. Le temps est représenté comme le nombre de millisecondes depuis l'époque Unix (1970-01-01T00:00:00Z).	Non
updated_at	`number`	Heure à laquelle les informations de l'utilisateur final ont été mises à jour pour la dernière fois. Le temps est représenté comme le nombre de millisecondes depuis l'époque Unix (1970-01-01T00:00:00Z).	Non

D'autres revendications standard incluent family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo, et locale seront également incluses dans la portée profile sans avoir besoin de demander le point de terminaison userinfo. Une différence par rapport aux revendications ci-dessus est que ces revendications ne seront renvoyées que lorsque leurs valeurs ne sont pas vides, tandis que les revendications ci-dessus renverront null si les valeurs sont vides.

remarque

Contrairement aux revendications standard, les revendications created_at et updated_at utilisent des millisecondes au lieu de secondes.

email

Nom de la revendication	Type	Description	Besoin d'userinfo ?
email	`string`	L'adresse e-mail de l'utilisateur	Non
email_verified	`boolean`	Si l'adresse e-mail a été vérifiée	Non

phone

Nom de la revendication	Type	Description	Besoin d'userinfo ?
phone_number	`string`	Le numéro de téléphone de l'utilisateur	Non
phone_number_verified	`boolean`	Si le numéro de téléphone a été vérifié	Non

address

Veuillez vous référer à OpenID Connect Core 1.0 pour les détails de la revendication d'adresse.

custom_data

Nom de la revendication	Type	Description	Besoin d'userinfo ?
custom_data	`object`	Les données personnalisées de l'utilisateur	Oui

identities

Nom de la revendication	Type	Description	Besoin d'userinfo ?
identities	`object`	Les identités liées de l'utilisateur	Oui
sso_identities	`array`	Les identités SSO liées de l'utilisateur	Oui

urn:logto:scope:organizations

Nom de la revendication	Type	Description	Besoin d'userinfo ?
organizations	`string[]`	Les identifiants d'organisation auxquels l'utilisateur appartient	Non
organization_data	`object[]`	Les données d'organisation auxquelles l'utilisateur appartient	Oui

urn:logto:scope:organization_roles

Nom de la revendication	Type	Description	Besoin d'userinfo ?
organization_roles	`string[]`	Les rôles d'organisation auxquels l'utilisateur appartient avec le format `<organization_id>:<role_name>`	Non

En considérant la performance et la taille des données, si "Besoin d'userinfo ?" est "Oui", cela signifie que la revendication n'apparaîtra pas dans le Jeton d’identifiant (ID token), mais sera renvoyée dans la réponse du point de terminaison userinfo.

Ressources API

Nous vous recommandons de lire d'abord 🔐 Contrôle d’accès basé sur les rôles (RBAC) pour comprendre les concepts de base de Logto RBAC et comment configurer correctement les ressources API.

Configurer le client Logto

Une fois que vous avez configuré les ressources API, vous pouvez les ajouter lors de la configuration de Logto dans votre application :

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

  // Assigner l'instance \`logtoClient\` à l'objet window,
  // permettant une utilisation globale dans d'autres pages
  window.logtoClient = new LogtoClient({
    endpoint: '<your-logto-endpoint>', // Par exemple http://localhost:3001
    appId: '<your-application-id>',
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // Ajouter des ressources API
  });
</script>

Chaque ressource API a ses propres permissions (portées).

Par exemple, la ressource https://shopping.your-app.com/api a les permissions shopping:read et shopping:write, et la ressource https://store.your-app.com/api a les permissions store:read et store:write.

Pour demander ces permissions, vous pouvez les ajouter lors de la configuration de Logto dans votre application :

<script type="module">
  // Importer le SDK \`@logto/browser\` depuis le CDN jsdelivr
  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>

Vous pouvez remarquer que les portées sont définies séparément des ressources API. Cela est dû au fait que les Indicateurs de ressource pour OAuth 2.0 spécifient que les portées finales pour la requête seront le produit cartésien de toutes les portées de tous les services cibles.

Ainsi, dans le cas ci-dessus, les portées peuvent être simplifiées à partir de la définition dans Logto, les deux ressources API peuvent avoir les portées read et write sans le préfixe. Ensuite, dans la configuration de Logto :

<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: ['read', 'write'],
    resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
  });
</script>

Pour chaque ressource API, il demandera à la fois les portées read et write.

remarque

Il est acceptable de demander des portées qui ne sont pas définies dans les ressources API. Par exemple, vous pouvez demander la portée email même si les ressources API n'ont pas la portée email disponible. Les portées non disponibles seront ignorées en toute sécurité.

Après une connexion réussie, Logto émettra les portées appropriées aux ressources API en fonction des rôles de l'utilisateur.

Récupérer le jeton d’accès pour la ressource API

Pour récupérer le jeton d’accès pour une ressource API spécifique, vous pouvez utiliser la méthode getAccessToken :

const isAuthenticated = await logtoClient.isAuthenticated();

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

Cette méthode renverra un jeton d’accès JWT qui peut être utilisé pour accéder à la ressource API lorsque l’utilisateur a les Permissions associées. Si le jeton d’accès mis en cache actuel a expiré, cette méthode essaiera automatiquement d’utiliser un jeton de rafraîchissement pour obtenir un nouveau jeton d’accès.

Récupérer les jetons d’organisation

Si l'Organisation est nouvelle pour vous, veuillez lire 🏢 Organisations (Multi-tenancy) pour commencer.

Vous devez ajouter la portée UserScope.Organisations lors de la configuration du client Logto :

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

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

Une fois l'utilisateur connecté, vous pouvez récupérer le jeton d’organisation pour l'utilisateur :

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

const isAuthenticated = await logtoClient.isAuthenticated();

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

  console.log('Revendications du jeton d’identifiant :', claims);
  console.log('Identifiants des organisations :', claims.organizations);

  // En supposant qu'il y ait au moins une organisation, prenons la première
  const organizationId = claims.organizations[0];
  const token = await logtoClient.getOrganizationToken(organizationId);

  console.log('Jeton d’accès de l’organisation :', token);
})();

Lectures complémentaires

Flux utilisateur final : flux d'authentification, flux de compte et flux d'organisation Configurer les connecteurs Protéger votre API

Prérequis​

Intégration​

Initier le fournisseur Logto​

Implémenter la connexion​

Configurer l'URI de redirection de connexion​

Implémenter un bouton de connexion​

Gérer la redirection​

Implémenter la déconnexion​

Implémenter un bouton de déconnexion​

Gérer le statut d'authentification​

Point de contrôle : Testez votre site Webflow​

Obtenir des informations sur l'utilisateur​

Ressources API​

Configurer le client Logto​

Récupérer le jeton d’accès pour la ressource API​

Récupérer les jetons d’organisation​

Lectures complémentaires​

Prérequis

Intégration

Initier le fournisseur Logto

Implémenter la connexion

Configurer l'URI de redirection de connexion

Implémenter un bouton de connexion

Gérer la redirection

Implémenter la déconnexion

Implémenter un bouton de déconnexion

Gérer le statut d'authentification

Point de contrôle : Testez votre site Webflow

Obtenir des informations sur l'utilisateur

Ressources API

Configurer le client Logto

Récupérer le jeton d’accès pour la ressource API

Récupérer les jetons d’organisation

Lectures complémentaires