RBAC en pratique : Implémentation d'une autorisation sécurisée pour votre application
Guide complet du contrôle d'accès basé sur les rôles (RBAC) : Maîtriser la conception des permissions, la gestion des rôles et l'autorisation sécurisée avec une implémentation CMS pratique.
YijunDeveloper
Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Avez-vous du mal à mettre en œuvre un système d'autorisation sécurisé et évolutif pour votre application ? Le contrôle d'accès basé sur les rôles (RBAC) est la norme de l'industrie pour gérer les permissions des utilisateurs, mais l'implémenter correctement peut être un défi. Ce tutoriel vous montrera comment construire un système RBAC robuste en utilisant un exemple concret de système de gestion de contenu (CMS).
En suivant ce guide, vous apprendrez :
✨ Comment concevoir et mettre en œuvre des permissions fines qui vous donnent un contrôle précis
🔒 Meilleures pratiques pour organiser les permissions en rôles significatifs
👤 Techniques pour gérer efficacement la propriété des ressources
🚀 Moyens de rendre votre système d'autorisation évolutif et facile à maintenir
💡 Mise en œuvre pratique en utilisant un exemple réel de CMS
Le code source complet de ce tutoriel est disponible sur GitHub.
Le contrôle d'accès basé sur les rôles est plus que simplement attribuer des permissions aux utilisateurs. Il s'agit de créer une approche structurée de l'autorisation qui équilibre sécurité et facilité de maintenance.
Vous pouvez en apprendre davantage sur Qu'est-ce que RBAC dans l'Auth Wiki.
Voici les principes clés que nous suivrons dans notre implémentation :
Les permissions fines vous donnent un contrôle précis sur ce que les utilisateurs peuvent faire dans votre système. Au lieu de niveaux d'accès larges comme "admin" ou "utilisateur", nous définissons des actions spécifiques que les utilisateurs peuvent effectuer sur les ressources. Par exemple :
read:articles - Voir n'importe quel article dans le système
create:articles - Créer de nouveaux articles
update:articles - Modifier les articles existants
publish:articles - Changer l'état de publication des articles
La propriété des ressources est un concept fondamental dans la conception d'autorisation de notre CMS. Bien que le RBAC définisse quelles actions différents rôles peuvent effectuer, la propriété ajoute une dimension personnelle au contrôle d'accès :
Les auteurs ont automatiquement accès aux articles qu'ils ont créés
Ce modèle de propriété naturelle signifie que les auteurs peuvent toujours voir et éditer leur propre contenu
Le système vérifie à la fois les permissions de rôle OU la propriété lorsqu'il gère les opérations d'article
Par exemple, même sans la permission update:articles, un auteur peut toujours éditer ses propres articles
Cette conception réduit le besoin de permissions de rôle supplémentaires tout en maintenant la sécurité
Cette approche à double couche (rôles + propriété) crée un système plus intuitif et sécurisé. Les éditeurs et admins peuvent toujours gérer tout le contenu par le biais de leurs permissions de rôle, tandis que les auteurs maintiennent le contrôle sur leur propre travail.
En fonction de nos exigences d'accès à l'API, nous pouvons définir ces permissions :
Permission
Description
list:articles
Voir la liste de tous les articles dans le système
read:articles
Lire le contenu complet de n'importe quel article
create:articles
Créer de nouveaux articles
update:articles
Modifier n'importe quel article
delete:articles
Supprimer n'importe quel article
publish:articles
Changer le statut de publication
Notez que ces permissions ne sont nécessaires que lors de l'accès aux ressources que vous ne possédez pas. Les propriétaires d'articles peuvent automatiquement :
Voir leurs propres articles (pas besoin de read:articles)
Éditer leurs propres articles (pas besoin de update:articles)
Supprimer leurs propres articles (pas besoin de delete:articles)
Maintenant que nous avons défini notre API et nos permissions, nous pouvons créer des rôles qui regroupent ces permissions de manière logique :
Permission/Rôle
👑 Admin
📝 Éditeur
✍️ Auteur
Description
Accès complet au système pour la gestion complète du contenu
Peut voir tous les articles et contrôler le statut de publication
Peut créer de nouveaux articles dans le système
list:articles
✅
✅
❌
read:articles
✅
✅
❌
create:articles
✅
❌
✅
update:articles
✅
❌
❌
delete:articles
✅
❌
❌
publish:articles
✅
✅
❌
Note : Les auteurs ont automatiquement les permissions de lecture/mise à jour/suppression pour leurs propres articles, indépendamment des permissions de rôle.
Chaque rôle est conçu avec des responsabilités spécifiques en tête :
Admin : A un contrôle complet sur le CMS, y compris toutes les opérations d'article
Éditeur : Se concentre sur la révision du contenu et la gestion de la publication
Auteur : Se spécialise dans la création de contenu
Cette structure de rôle crée une séparation claire des préoccupations :
Les auteurs se concentrent sur la création de contenu
Les éditeurs gèrent la qualité et la visibilité du contenu
Les admins maintiennent le contrôle global du système
Avant de commencer, vous devez créer un compte dans Logto Cloud, ou vous pouvez également utiliser une instance Logto auto-hébergée en utilisant la version OSS de Logto.
Mais pour ce tutoriel, nous utiliserons Logto Cloud pour plus de simplicité.
Dans notre exemple, nous utilisons React pour la démonstration.
Après avoir configuré Logto dans votre application, nous devons ajouter les configurations RBAC pour que Logto fonctionne.
N'oubliez pas de vous déconnecter et de vous reconnecter pour que ce changement prenne effet si vous êtes déjà connecté.
Lorsque l'utilisateur se connecte avec Logto et demande un jeton d'accès pour les ressources API spécifiées ci-dessus, Logto ajoutera les scopes (permissions) liés au rôle de l'utilisateur au jeton d'accès.
Vous pouvez utiliser getAccessTokenClaims du hook useLogto pour obtenir les scopes du jeton d'accès.
Et vous pouvez utiliser userScopes pour vérifier si l'utilisateur a la permission d'accéder à la ressource.
Tout d'abord, nous devons ajouter un middleware dans le backend pour vérifier les permissions des utilisateurs, vérifier si l'utilisateur est connecté et déterminer s'il dispose des permissions nécessaires pour accéder à certaines API.
Comme vous pouvez le voir, dans ce middleware, nous vérifions si la requête du frontend contient un jeton d'accès valide et nous vérifions si l'audience du jeton d'accès correspond à la ressource API que nous avons créée dans la console Logto.
La raison pour laquelle nous vérifions la ressource API est que notre ressource API représente en réalité les ressources de notre backend CMS, et toutes les permissions de notre CMS sont associées à cette ressource API.
Étant donné que cette ressource API représente les ressources CMS dans Logto, dans notre code frontend, nous incluons le Jeton d'accès correspondant lors des requêtes API vers le backend :
Nous pouvons maintenant utiliser le middleware requireAuth pour protéger nos points de terminaison API.
Pour les APIs qui ne devraient être accessibles qu'aux utilisateurs ayant des permissions spécifiques, nous pouvons ajouter des restrictions directement dans le middleware. Par exemple, l'API de création d'article ne devrait être accessible qu'aux utilisateurs ayant la permission create:articles :
Pour les APIs qui nécessitent de vérifier à la fois les permissions et la propriété des ressources, nous pouvons utiliser la fonction hasScopes. Par exemple, dans l'API de liste d'articles, les utilisateurs avec la permission list:articles peuvent accéder à tous les articles, tandis que les auteurs peuvent accéder à leurs propres articles créés :
À ce stade, nous avons complété l'implémentation du RBAC. Vous pouvez consulter le code source complet pour voir l'implémentation complète.
