## Contexte La semaine dernière, nous avons présenté la [fonctionnalité de collaboration](https://blog.logto.io/releases/2024-apr/) sur Logto Cloud. Si vous l'avez manquée, jetez-y un coup d'œil ! Désormais, vous pouvez inviter des collègues et collaborateurs à vos locataires Logto existants, en collaborant ensemble à la gestion du système d'identité pour vos applications. Dans cette nouvelle version, nous avons ajouté deux rôles à chaque locataire Logto : - **Administrateur** : Accès complet au locataire, y compris la gestion des ressources liées à l'identité, l'invitation et la gestion des autres membres, la gestion de la facturation, et la consultation de l'historique des factures. - **Collaborateur** : Peut gérer les ressources liées à l'identité mais n'a pas accès aux autres fonctionnalités administratives. Conformément à notre engagement à utiliser nos propres outils, nous avons exploité notre fonctionnalité RBAC (Contrôle d'Accès Basé sur les Rôles) et notre fonctionnalité Organisations pour construire la collaboration utilisateur. Si vous êtes novice en matière de RBAC, consultez [notre article précédent](https://blog.logto.io/mastering-rbac/) pour commencer. Dans cet article de blog, examinons ce qui a été nécessaire pour mettre en œuvre cette fonctionnalité, et comment ces pratiques pourraient vous être utiles si vous développez des applications multi-organisations. ## La collaboration sur Logto Cloud est construite avec Logto Organizations Chaque locataire de Logto Cloud fonctionne comme une organisation indépendante dans notre système, propulsée par notre propre fonctionnalité Organisations. Pour introduire les rôles d'administrateur de locataire et de collaborateur, nous avons créé deux rôles d'organisation dans le modèle d'organisation, chacun attribué à un ensemble spécifique de permissions d'organisation.

## Gestion des invitations avec l'API de gestion de Logto Nous avons fourni un ensemble d'API de gestion liées aux invitations dans la fonctionnalité organisations. Avec ces API, vous pouvez, par exemple : - `POST /api/organization-invitations` créer et envoyer une invitation d'organisation à une adresse email - `GET /api/organization-invitations` & `GET /api/organization-invitations/{id}` accéder à vos invitations - `PUT /api/organization-invitations/{id}/status` accepter ou refuser l'invitation en mettant à jour le statut de l'invitation Pour plus de détails, consultez la [documentation complète de l'API](https://openapi.logto.io/group/endpoint-organization-invitations). ## Connectez votre connecteur de messagerie Comme les invitations sont envoyées par email, assurez-vous que votre connecteur de messagerie est correctement configuré. Dans cette version, nous avons introduit un nouveau type d'utilisation de modèle de mail, `OrganizationInvitation`, permettant la personnalisation du modèle de mail d'invitation. Exemple d'email d'invitation

Ce modèle de mail acceptera par défaut une variable `{{link}}`, qui est le lien vers la page d'accueil de la console Logto, où les utilisateurs peuvent accepter l'invitation et rejoindre un locataire de Logto. Une des pages d'accueil sur Logto Cloud ressemble à la capture d'écran ci-dessous : Page d'accueil d'invitation

Référez-vous à la [documentation de l'API](https://openapi.logto.io/operation/operation-post-api-organization-invitations-parameter-message) pour plus de détails sur l'envoi de l'email d'invitation via l'API de gestion. ## Utilisez RBAC pour gérer les permissions utilisateurs Avec ces configurations, nous pouvons envoyer des invitations par email, et les invités peuvent rejoindre l'organisation avec le rôle assigné. Les utilisateurs avec différents rôles d'organisation auront des portées (permissions) différentes dans leurs jetons d'accès. Ainsi, à la fois l'application cliente (Logto Console) et nos services backend devraient vérifier ces portées pour déterminer les fonctionnalités visibles et les actions permises. Très bien, jusqu'ici tout semble connecté, et qu'est-ce qu'il nous manque encore ? ## Gérer les mises à jour des portées dans les jetons d'accès La gestion des mises à jour des portées dans les jetons d'accès implique : - **Révoquer les portées existantes** : Par exemple, rétrograder un administrateur à collaborateur non-admin réduit automatiquement les portées dans le nouveau jeton d'accès obtenu avec le jeton de rafraîchissement existant. - **Accorder de nouvelles portées** : À l'inverse, promouvoir un utilisateur en administrateur nécessite de déclencher un nouveau processus d'authentification ou de reconsentement pour refléter le changement dans les jetons d'accès des utilisateurs. Sur Logto Cloud, la Console vérifie activement les portées des utilisateurs en utilisant des requêtes [SWR](https://swr.vercel.app/), et nous appliquons automatiquement le consentement chaque fois qu'un utilisateur est promu administrateur. Si vous mettez en œuvre une fonctionnalité similaire avec RBAC, vous aurez besoin d'un mécanisme (par exemple, WebSocket ou événements serveur-poussé) pour notifier votre application des mises à jour des portées, permettant le reconsentement ou l'émission de nouveaux jetons d'accès en conséquence. Logto fournira également plus de webhooks pour assister avec cela dans de futures mises à jour. ## En résumé Les fonctionnalités multi-locataires et de collaboration de Logto Cloud exploitent notre fonctionnalité Organisations. Si vous développez une application multi-locataire similaire, envisagez d'utiliser cette fonctionnalité avec des approches similaires. J'espère que cet article de blog vous a été utile. Pour des questions ou des discussions, n'hésitez pas à rejoindre notre [canal Discord](https://discord.gg/UEPaF3j5e6).