Construire une application SaaS multi-locataire : Un guide complet de la conception à la mise en œuvre
Apprenez à construire efficacement une application SaaS multi-locataire avec une authentification robuste, une gestion des organisations, et un contrôle d'accès basé sur les rôles en seulement quelques heures.
Comment des applications comme "Notion", "Slack", ou "Figma" sont-elles construites ? Ces applications SaaS multi-locataires semblent simples à utiliser, mais en construire une soi-même ? C'est une autre histoire.
Quand j'ai d'abord pensé à construire un tel monstre complexe, mon esprit a explosé :
- Les utilisateurs ont besoin de plusieurs options de connexion (email, Google, GitHub)
- Chaque utilisateur peut créer et appartenir à plusieurs organisations
- Différents niveaux de permission au sein de chaque organisation
- Les organisations d'entreprise nécessitent une adhésion automatique pour des domaines d'email spécifiques
- Exigences MFA pour les opérations sensibles
- ...
"Patron, parlons de la conception du produit dans deux semaines. Je suis dans le pétrin maintenant."
Mais lorsque j'ai réellement commencé à y travailler, j'ai découvert que ce n'était pas aussi intimidant qu'il n'y paraissait.
J'ai juste construit un système avec toutes ces fonctionnalités en MOINS DE 2 HEURES !
Je vais vous montrer exactement comment concevoir et implémenter un tel système depuis le début - et vous serez étonné de voir à quel point c'est vraiment simple en 2025 avec des outils modernes et une approche architecturale adéquate.
Le code source complet est disponible à la fin de cet article. Plongeons dans le sujet !
Nous commencerons par un produit SaaS de documentation AI appelé "DocuMind".
"DocuMind" est un produit SaaS de documentation AI conçu avec un modèle multi-locataire pour prendre en charge les utilisateurs individuels, les petites entreprises et les grandes entreprises.
La plateforme offre de puissantes capacités AI pour la gestion de documents, y compris la génération automatique de résumés, l'extraction de points clés, et des recommandations de contenu intelligent au sein des organisations.
Quelles fonctionnalités sont nécessaires pour l'authentification et l'autorisation SaaS ?
D'abord, passons en revue les exigences nécessaires. De quelles fonctionnalités avez-vous besoin ?
Architecture multi-locataire
Pour permettre une architecture multi-locataire, vous aurez besoin d'une couche d'entité appelée organisation. Imaginez avoir une seule piscine d'utilisateurs qui peuvent accéder à plusieurs espaces de travail. Chaque organisation représente un espace de travail, et les utilisateurs conservent une identité unique tout en accédant à différents espaces de travail (organisations) en fonction de leurs rôles assignés.
C’est une fonctionnalité largement utilisée chez les fournisseurs d'authentification. Une organisation dans un système de gestion d'identité correspond à l'espace de travail, au projet ou au locataire de votre application SaaS.
Adhésion
Un membre est un concept temporaire utilisé pour indiquer le statut d'adhésion d'une identité au sein d'une organisation.
Par exemple, Sarah s'inscrit à votre application en utilisant son email, [email protected]. Elle peut appartenir à différents espaces de travail. Si Sarah fait partie de l'Espace de travail A mais pas de l'Espace de travail B, elle est considérée comme membre de l'Espace de travail A mais pas de l'Espace de travail B.
Conception des rôles et des permissions
Dans une architecture multi-locataire, les utilisateurs ont besoin de rôles avec des permissions spécifiques pour accéder à leurs ressources locataires.
Les permissions sont des contrôles d'accès détaillés qui définissent des actions spécifiques, comme lire : commande
ou écrire : commande
. Elles déterminent quelles actions peuvent être exécutées sur des ressources particulières.
Les rôles sont un ensemble de permissions assignées aux membres dans un environnement multi-locataire.
Vous devrez définir ces rôles et permissions, puis assigner des rôles aux utilisateurs, et cela peut parfois inclure des processus automatisés. Par exemple :
- Les utilisateurs qui rejoignent une organisation obtiennent automatiquement le rôle de membre.
- Le premier utilisateur à créer un espace de travail se voit automatiquement attribuer le rôle d'administrateur.
Flux d'inscription et de connexion
Assurez un processus d'enregistrement et d'authentification convivial et sécurisé, incluant des options de connexion et d'inscription basiques :
- Connexion par email et mot de passe : Méthode de connexion traditionnelle avec email et mot de passe.
- Connexion sans mot de passe : Utilisez des codes de vérification par email pour un accès facile et sécurisé.
- Gestion du compte : Un centre de compte où les utilisateurs peuvent mettre à jour leur email, mot de passe, et autres détails.
- Connexion sociale : Options comme Google et GitHub pour une connexion rapide.
- Authentification multi-facteurs (MFA) : Améliorez la sécurité en permettant la connexion via des applications authentificatrices comme Duo.
Création et invitation de locataires
Dans une application SaaS multi-locataire, une différence clé dans le flux utilisateur est la nécessité de prendre en charge la création de locataires et les invitations de membres. Ce processus nécessite une planification et une exécution minutieuses, car il joue un rôle clé dans l'activation et la croissance du produit.
Voici quelques flux d'utilisation typiques à considérer :
Type d'utilisateur | Point d'entrée |
---|---|
Nouveau compte | Entrez depuis la page de connexion et d'inscription pour créer un nouveau locataire |
Compte existant | Créez un autre locataire au sein du produit |
Le compte existant a reçu une invitation de nouveau locataire | Entrez depuis la page de connexion et d'inscription |
Le compte existant a reçu une invitation de nouveau locataire | Entrez depuis l'email d'invitation |
Le nouveau compte a reçu une invitation de nouveau locataire | Entrez depuis la page de connexion et d'inscription |
Le nouveau compte a reçu une invitation de nouveau locataire | Entrez depuis l'email d'invitation |
Voici quelques scénarios courants que l'on trouve dans presque toutes les applications SaaS. Utilisez-les comme référence pour inspirer votre équipe produit et de conception, et n'hésitez pas à créer vos propres flux si nécessaire.
Architecture technique et conception du système
Une fois que nous avons compris toutes les exigences du produit, passons à la mise en œuvre.
Définir la stratégie d'authentification
L'authentification peut sembler effrayante. Les utilisateurs ont besoin :
- Inscription/connexion par email et mot de passe
- Connexion en un clic avec Google/Github
- Réinitialisation du mot de passe en cas d'oubli
- Connexion pour toute l'équipe pour les clients d'entreprise
- ...
Implémenter ces fonctionnalités de base pourrait prendre des semaines de développement.
Mais maintenant, nous n'avons pas besoin de construire TOUT cela nous-mêmes !
Les fournisseurs de solutions d'authentification modernes (je vais choisir Logto cette fois-ci) ont déjà emballé toutes ces fonctionnalités pour nous. Le flux d'authentification est simple :
De semaines de développement à 15 minutes de configuration, Logto gère tous les flux complexes pour nous ! Nous couvrirons les étapes d'intégration dans la section mise en œuvre plus tard. Maintenant, nous pouvons nous concentrer sur la construction des fonctionnalités de base de DocuMind !
Établir une architecture multi-locataire
Le système d'organisation permet aux utilisateurs de créer et de rejoindre plusieurs organisations. Comprenons les relations fondamentales :
Dans ce système, chaque utilisateur peut appartenir à plusieurs organisations, et chaque organisation peut avoir plusieurs membres.
Activer le contrôle d'accès dans une application multi-locataire
Le contrôle d'accès basé sur les rôles (RBAC) est important pour garantir la sécurité et l'évolutivité des applications SaaS multi-locataires.
Dans une application multi-locataire, la conception des permissions et des rôles est généralement cohérente, car elle découle de la conception du produit. Par exemple, dans plusieurs espaces de travail, il y a généralement un rôle d'administrateur et un rôle de membre. Logto en tant que fournisseur d'authentification a la conception de contrôle d'accès basé sur les rôles au niveau de l'organisation suivante :
- Définitions unifiées des permissions : Les permissions sont définies au niveau du système et s'appliquent de manière cohérente à toutes les organisations, assurant une gestion des permissions maintenable et cohérente
- Modèles d'organisation : Combinaisons pré-définies de rôles et de permissions à travers des modèles d'organisation, simplifiant l'initialisation de l'organisation
La relation de permission ressemble à ça :
Comme chaque utilisateur a besoin de son propre(s) rôle(s) au sein de chaque organisation, la relation entre les rôles et les organisations doit refléter les rôles assignés à chaque utilisateur :
Nous avons conçu le système organisationnel et le système de contrôle d'accès, et maintenant nous pouvons commencer à construire notre produit !
Pile technologique
J'ai choisi une pile portable et conviviale pour les débutants :
- Frontend : React (facilement transférable à Vue/Angular/Svelte)
- Backend : Express (API simple et intuitive)
Pourquoi séparer le frontend et le backend ? Parce qu'il a une architecture claire, facile à apprendre et simple à changer de stacks. Et pour les fournisseurs d'authentification, j'utilise Logto comme exemple.
Et pour les guides suivants, les modèles ici fonctionnent avec : N'importe quel frontend, n'importe quel backend et n'importe quel système d'authentification.
Ajouter un flux d'authentification de base à votre application
C'est l'étape la plus facile. Nous devons juste intégrer Logto dans notre projet. Ensuite, nous pouvons configurer les méthodes de connexion/enregistrement des utilisateurs dans la Console Logto en fonction de nos besoins.
Installer Logto dans votre application
D'abord, connectez-vous à Logto Cloud. Vous pouvez vous inscrire pour un compte gratuit si vous n'en avez pas un. Créez un locataire de développement pour les tests.
Dans la console du locataire, cliquez sur le bouton "Application" à gauche. Ensuite, sélectionnez "React" pour commencer à construire notre application.
Suivez le guide sur la page. Vous pouvez compléter l'intégration de Logto en environ 5 minutes !
Voici mon code d'intégration :
Voici une astuce utile : notre page de connexion a des boutons Se connecter et S'inscrire. Le bouton S'inscrire mène directement à la page d'enregistrement de Logto. Cela fonctionne par l'écran de première étape de Logto. Cela détermine quelle étape du flux d'authentification les utilisateurs voient en premier.
Vous pouvez par défaut accéder à la page d'enregistrement lorsque votre produit attend beaucoup de nouveaux utilisateurs.
Après avoir cliqué sur Connexion, vous accéderez à la page de connexion Logto. Une fois la connexion (ou l'inscription) réussie, félicitations ! Votre application a son premier utilisateur (vous) !
Et appelez la fonction signOut
du hook useLogto
pour déconnecter l'utilisateur quand vous le souhaitez.
Personnaliser les méthodes de connexion et d'inscription
Dans la console Logto, cliquez sur "Expérience de connexion" dans le menu de gauche. Ensuite, cliquez sur l'onglet "Inscription et connexion". Sur cette page, suivez les instructions pour configurer les méthodes de connexion/enregistrement de Logto.
Et le flux de connexion ressemblera à ça :
Activer l'authentification multi-facteurs
Avec Logto, activer la MFA est simple. Il suffit de cliquer sur le bouton "Authentification multi-facteurs" dans la console Logto. Ensuite, activez-la sur la page d'authentification multi-facteurs.
Et le flux MFA ressemblera à ça :
Tout est si simple ! Nous avons mis en place un système d'authentification utilisateur complexe en quelques minutes seulement !
Ajouter une expérience organisationnelle multi-locataire
Nous avons maintenant notre premier utilisateur ! Cependant, cet utilisateur n'appartient à aucune organisation pour le moment, et nous n'avons créé aucune organisation.
Logto fournit un support intégré pour la multi-locataire. Vous pouvez créer n'importe quel nombre d'organisations dans Logto. Chaque organisation peut avoir plusieurs membres.
Chaque utilisateur peut obtenir ses informations d'organisation de Logto. Cela permet le support de la multi-locataire
Obtenir les informations d'organisation d'un utilisateur
Pour obtenir les informations d'organisation d'un utilisateur depuis Logto, suivez ces deux étapes :
Déclarer l'accès aux informations d'organisation dans le Logto Config. Cela se fait en définissant les scopes
et resources
appropriés.
Utilisez la méthode fetchUserInfo
de Logto pour obtenir les informations de l'utilisateur, y compris les données d'organisation.
Après avoir complété ces étapes, vous devez vous déconnecter et vous reconnecter. Cela est nécessaire car nous avons modifié la portée et la ressource demandées.
Pour l'instant, vous n'avez créé aucune organisation. L'utilisateur n'a rejoint aucune organisation non plus. Le tableau de bord affichera "Vous n'avez encore aucune organisation".
Ensuite, nous allons créer une organisation pour nos utilisateurs et les y ajouter.
Grâce à Logto, nous n'avons pas besoin de construire des relations d'organisation complexes. Nous devons juste créer une organisation dans Logto et y ajouter des utilisateurs. Logto gère toute la complexité pour nous. Il y a deux façons de créer des organisations :
- Créer manuellement des organisations via la console Logto
- Utiliser l'API de gestion Logto pour créer des organisations, surtout lors de la conception d'un flux SaaS qui permet aux utilisateurs de créer leurs propres organisations (espaces de travail).
Créer une organisation dans la console Logto
Cliquez sur le bouton "Organisations" dans le menu de gauche de la console Logto. Créez une organisation.
Maintenant, vous avez votre première organisation.
Ensuite, ajoutons l'utilisateur à cette organisation.
Allez sur la page des détails de l'organisation. Passez à l'onglet Membres. Cliquez sur le bouton "+ Ajouter un membre". Sélectionnez votre utilisateur connecté dans la liste de gauche. Cliquez sur le bouton "Ajouter des membres" en bas à droite. Vous avez maintenant ajouté avec succès l'utilisateur à cette organisation.
Rafraîchissez votre page APP. Vous verrez que l'utilisateur appartient maintenant à une organisation !
Implémenter une expérience de création de self-service organisationnel
Créer une organisation dans la console ne suffit pas. Votre application SaaS a besoin d'un flux qui permet aux utilisateurs finaux de créer et de gérer facilement leurs propres espaces de travail. Pour implémenter cette fonctionnalité, utilisez l'API de gestion Logto.
Pour obtenir des conseils, consultez la documentation Interagir avec l'API de gestion pour configurer la communication entre l'API et Logto.
Comprendre le flux d'interaction auth de l'organisation
Prenons le flux de création d'organisation comme exemple. Voici comment fonctionne le processus de création d'une organisation :
Ce flux a deux exigences d'authentification clés :
- Protection de l'API de service backend :
- L'accès au frontend à notre API de service backend nécessite une authentification
- Les endpoints de l'API sont protégés en validant le token d'accès Logto de l'utilisateur
- Assure que seuls les utilisateurs authentifiés peuvent accéder à nos services
- Accès à l'API de gestion Logto :
- Le service backend doit appeler en toute sécurité l'API de gestion Logto
- Suivez le guide Interagir avec l'API de gestion pour la configuration
- Utilisez l'authentification Machine-to-Machine pour obtenir des informations d'accès
Protéger votre API backend
Tout d'abord, créons un endpoint API dans notre service backend pour créer des organisations.
Notre API de service backend ne permet que les utilisateurs authentifiés. Nous devons utiliser Logto pour protéger notre API. Nous devons également connaître les informations de l'utilisateur actuel (comme l'ID utilisateur).
Dans le concept de Logto (et OAuth 2.0), notre service backend agit comme un serveur de ressources. Les utilisateurs accèdent au serveur de ressources DocuMind avec un jeton d'accès de l'interface utilisateur. Le serveur de ressources vérifie ce token. Si valide, il retourne les ressources demandées.
Créons une API Resource pour représenter notre service backend.
Allez à la console Logto.
- Cliquez sur le bouton "API resources" à droite.
- Cliquez sur "Create API resource". Sélectionnez Express dans le popup.
- Remplissez "DocuMind API" comme nom d'API. Utilisez "https://api.documind.com" comme identifiant API.
- Cliquez sur créer.
Ne vous inquiétez pas de cette URL d'identification API. C'est juste un identifiant unique pour votre API dans Logto. Ce n'est pas lié à votre URL de service backend réelle.
Vous verrez un tutoriel pour utiliser la resource API. Vous pouvez suivre ce tutoriel ou nos étapes ci-dessous.
Créons un middleware requireAuth pour protéger notre endpoint POST /organizations.
Pour utiliser ce middleware, nous avons besoin de ces variables d'environnement :
- LOGTO_JWKS_URL
- LOGTO_ISSUER
Obtenez ces variables depuis l'endpoint de configuration OpenID de votre locataire Logto. Visitez https://<votre-id-locataire>.logto.app/oidc/.well-known/openid-configuration
. Vous trouverez les informations nécessaires dans le JSON retourné :
Utilisons maintenant le middleware requireAuth dans notre endpoint POST /organizations.
Cela protège notre endpoint POST /organizations. Seuls les utilisateurs ayant des jetons d'accès Logto valides peuvent y accéder.
Nous pouvons désormais obtenir le token de Logto dans notre frontend. Les utilisateurs peuvent créer des organisations via notre API de service backend avec ce token. Le middleware nous donne également l'ID utilisateur, ce qui est utile pour ajouter des utilisateurs aux organisations.
Dans le code frontend, déclarer cette resource API dans le config Logto. Ajouter son identifiant au tableau de resources.
Comme avant, les utilisateurs doivent se reconnecter après que nous ayons mis à jour le config Logto.
Dans le tableau de bord, obtenez le token d'accès Logto lors de la création d'une organisation. Utilisez ce token pour accéder à notre API de service backend.
Nous pouvons maintenant accéder correctement à l'API de service backend DocuMind.
Appeler l'API de gestion Logto
Implémentons la création d'organisation en utilisant l'API de gestion Logto.
Comme les requêtes frontend au service backend, les requêtes de service backend à Logto nécessitent des jetons d'accès.
Dans Logto, nous utilisons l'authentification Machine-to-Machine pour les jetons d'accès. Voir Interagir avec l'API de gestion.
Allez à la page des applications dans la console Logto. Créez une application Machine-to-Machine. Attribuez le rôle "Accès API de gestion Logto". Copiez l'endpoint Token, l'App ID, et l'App Secret. Nous les utiliserons pour les jetons d'accès.
Nous pouvons maintenant obtenir des jetons d'accès à l'API de gestion Logto par le biais de cette application M2M.
Utilisez ce token d'accès pour appeler l'API de gestion Logto.
Nous utiliserons ces API de gestion :
POST /api/organizations
: Créer organisation (voir : Référence de l'API de création d'organisation)POST /api/organizations/{id}/users
: Ajouter des utilisateurs à l'organisation (voir : Référence de l'API d'ajout d'utilisateurs)
Nous avons maintenant implémenté la création d'organisation avec l'API de gestion Logto. Nous pouvons également ajouter des utilisateurs aux organisations.
Testons cette fonctionnalité dans le tableau de bord.
et cliquez sur "Créer une organisation"
Création réussie !
La prochaine étape consisterait à inviter des utilisateurs à une organisation. Nous n'implémenterons pas cette fonctionnalité dans notre tutoriel pour l'instant. Vous savez déjà comment utiliser l'API de gestion. Vous pouvez vous référer à ce Création et invitation de locataire comme référence de conception produit et implémenter facilement cette fonctionnalité en suivant cet article de blog : Comment nous mettons en œuvre la collaboration utilisateur dans une application multi-locataire.
Implémenter le contrôle d'accès à votre application multi-locataire
Passons maintenant au contrôle d'accès de l'organisation.
Nous voulons atteindre :
- Les utilisateurs peuvent uniquement accéder aux ressources appartenant à leurs propres organisations : Cela peut être fait via le
jeton d'organisation
de Logto - Les utilisateurs ont des rôles spécifiques au sein des organisations (contenant différentes permissions) pour effectuer des actions autorisées : Cela peut être implémenté grâce à la fonctionnalité du modèle d'organisation de Logto
Voyons comment implémenter ces fonctionnalités.
Utilisation du jeton d'organisation Logto
Semblable au jeton d'accès Logto mentionné plus tôt, Logto émet un jeton d'accès correspondant à une ressource spécifique, et les utilisateurs utilisent ce jeton pour accéder aux ressources protégées dans le service backend. En correspondance, Logto émet un jeton d'organisation correspondant à une organisation spécifique, et les utilisateurs utilisent ce jeton pour accéder aux ressources d'organisation protégées dans le service backend.
Dans l'application frontend, nous pouvons utiliser la méthode getOrganizationToken
de Logto pour obtenir un jeton d'accès à une organisation spécifique.
Ici, organizationId
est l'identifiant de l'organisation à laquelle l'utilisateur appartient.
Avant d'utiliser getOrganization
ou toute fonctionnalité organisationnelle, nous devons nous assurer que l'étendue urn:logto:scope:organizations
et la ressource urn:logto:resource:organization
sont incluses dans le config Logto. Puisque nous les avons déjà déclarées plus tôt, nous ne répéterons pas.
Dans notre page d'organisation, nous utilisons le jeton d'organisation pour récupérer les documents au sein de l'organisation.
Il y a deux points importants à noter dans cette implémentation :
- Si le
organizationId
passé àgetOrganizationToken
n'est pas un identifiant d'organisation qui appartient à l'utilisateur actuel, cette méthode ne pourra pas obtenir de jeton, assurant ainsi que les utilisateurs ne peuvent accéder qu'à leurs propres organisations. - Lors de la demande de ressources organisationnelles, nous utilisons le token d'organisation au lieu du token d'accès car pour les ressources appartenant à une organisation, nous voulons utiliser le contrôle d'accès de l'organisation plutôt que le contrôle d'accès de l'utilisateur (vous comprendrez mieux cela lorsque nous implémenterons l'API
GET /documents
plus tard).
Ensuite, nous créons une API GET /documents
dans notre service backend. Semblable à la façon dont nous utilisons la resource API pour protéger l'API POST /organizations
, nous utilisons des indicateurs de resource spécifiques à l'organisation pour protéger l'API GET /documents
.
Tout d'abord, créons un middleware requireOrganizationAccess
pour protéger les ressources de l'organisation.
Ensuite, nous utilisons le middleware requireOrganizationAccess
pour protéger l'API GET /documents
.
De cette façon, nous avons implémenté l'utilisation de tokens d'organisation pour accéder aux ressources organisationnelles. Dans le service backend, vous pouvez récupérer les ressources correspondantes à partir de la base de données en fonction de l'identifiant de l'organisation.
Certains logiciels nécessitent une isolation des données entre les organisations. Pour une discussion et une implémentation plus approfondies, vous pouvez consulter l'article de blog : Implémentation de la multi-location avec PostgreSQL : Apprenez à travers un exemple réel simple.
Implémenter la conception du contrôle d'accès basé sur les rôles au niveau de l'organisation
Nous avons implémenté l'utilisation de tokens d'organisation pour accéder aux ressources organisationnelles. Ensuite, nous allons implémenter le contrôle des permissions des utilisateurs au sein des organisations en utilisant la RBAC.
Supposons que DocuMind ait deux rôles : Administrateur et Collaborateur.
Les administrateurs peuvent créer et accéder aux documents, tandis que les collaborateurs ne peuvent qu'accéder aux documents.
Par conséquent, notre organisation doit avoir ces deux rôles : Administrateur et Collaborateur.
L'administrateur a à la fois les permissions lire:documents
et créer:documents
, tandis que le collaborateur n'a que la permission lire:documents
.
- Administrateur
lire:documents
créer:documents
- Collaborateur
lire:documents
C'est là qu'intervient la fonctionnalité de modèle d'organisation de Logto.
Un modèle d'organisation est un modèle de l'accès au contrôle de chaque organisation : il définit les rôles et les permissions qui s'appliquent à toutes les organisations.
Pourquoi le modèle d'organisation ?
Parce que l'évolutivité est l'une des exigences les plus importantes pour les produits SaaS. En d'autres termes, ce qui fonctionne pour un client devrait fonctionner pour tous les clients.
Allons à la console Logto > Modèles d'organisation > Permissions d'organisation et créons deux permissions : lire:documents
et créer:documents
.
Ensuite, allez dans l'onglet rôles d'organisation pour créer deux rôles utilisateurs : Administrateur et Collaborateur, et attribuer des permissions correspondantes à ces rôles.
De cette façon, nous avons créé un modèle d'accès aux permissions RBAC pour chaque organisation.
Ensuite, nous allons à notre page de détails de l'organisation pour attribuer des rôles appropriés à nos membres.
Maintenant, nos utilisateurs d'organisation ont des rôles ! Vous pouvez effectuer ces étapes via l'API de gestion Logto :
Nous pouvons maintenant implémenter le contrôle des permissions utilisateur en vérifiant leurs permissions.
Dans notre code, nous devons faire en sorte que le token d'organisation de l'utilisateur transporte des informations sur les permissions, puis vérifier ces permissions dans le backend.
Dans le config de Logto du code frontend, nous devons déclarer les permissions que les utilisateurs doivent demander au sein de l'organisation. Ajoutons les permissions lire:documents
et créer:documents
aux scopes
.
Comme d'habitude, connectez-vous à nouveau avec votre utilisateur pour que ces configurations prennent effet.
Ensuite, dans le middleware requireOrganizationAccess
du backend, nous ajoutons la vérification des permissions utilisateur.
Ensuite, créez une API POST /documents, et utilisez le middleware requireOrganizationAccess
avec la configuration des scopes requis pour protéger cette API et l'API précédente GET /documents
.
De cette façon, nous avons implémenté le contrôle des permissions utilisateur en vérifiant les permissions utilisateur.
Dans le frontend, vous pouvez obtenir des informations sur les permissions utilisateur en décodant le token d'organisation ou en appelant la méthode getOrganizationTokenClaims
de Logto.
Contrôlez les éléments de la page en fonction des permissions utilisateur en vérifiant les scopes dans les claims.
Ajouter plus de fonctionnalités à l'application multi-locataire
Jusqu'à présent, nous avons implémenté les fonctionnalités de base pour les utilisateurs et les organisations dans un système SaaS multi-locataire ! Cependant, certaines fonctionnalités ne sont pas encore couvertes, telles que la personnalisation de la marque de la page de connexion pour chaque organisation, l'ajout automatique d'utilisateurs avec des emails de domaine spécifiques à certaines organisations, et l'intégration de la fonctionnalité SSO au niveau de l'entreprise.
Ce sont toutes des fonctionnalités prêtes à l'emploi, et vous pouvez trouver plus d'informations sur ces fonctionnalités dans la documentation de Logto.
Fonctionnalités | Lien Doc |
---|---|
Intégration SSO d'entreprise | https://docs.logto.io/end-user-flows/enterprise-sso |
Provisionnement Just-in-Time (JIT) | https://docs.logto.io/organizations/just-in-time-provisioning |
Branding au niveau de l'organisation | https://docs.logto.io/customization/match-your-brand#organization-specific-branding |
Authentification multi-facteurs (MFA) au niveau de l'organisation | https://docs.logto.io/organizations/organization-management#require-mfa-for-organization-members |
Gestion au niveau de l'organisation : | https://docs.logto.io/end-user-flows/organization-experience/organization-management |
Résumé
Rappelez-vous à quel point cela semblait accablant au début ? Utilisateurs, organisations, permissions, fonctionnalités d'entreprise... cela semblait être une montagne interminable à gravir.
Mais regardez ce que nous avons accompli :
- Un système d'authentification complet avec de multiples options de connexion et le support de la MFA
- Un système organisationnel flexible qui prend en charge de multiples adhésions
- Un contrôle d'accès basé sur les rôles au sein des organisations
Et la meilleure partie ? Nous n'avons pas eu besoin de réinventer la roue. En tirant parti d'outils modernes comme Logto, nous avons transformé ce qui aurait pu être des mois de développement en quelques heures.
Le code source complet de ce tutoriel est disponible à l'adresse suivante : Exemple de SaaS multi-locataire.
C'est la puissance du développement moderne en 2025 - nous pouvons nous concentrer sur la création de fonctionnalités uniques au produit au lieu de nous battre avec l'infrastructure. Maintenant, c'est à votre tour de construire quelque chose d'incroyable !
Explorez toutes les fonctionnalités de Logto, de Logto Cloud à Logto OSS, sur le site Web de Logto ou inscrivez-vous sur Logto cloud dès aujourd'hui.