Guía completa de Control de Acceso Basado en Roles (RBAC): Domina el diseño de permisos, la gestión de roles y la autorización segura con una implementación práctica de CMS.
¿Estás luchando con la implementación de un sistema de autorización seguro y escalable para tu aplicación? El Control de Acceso Basado en Roles (RBAC) es el estándar de la industria para gestionar los permisos de usuarios, pero implementarlo correctamente puede ser un desafío. Este tutorial te mostrará cómo construir un sistema RBAC robusto usando un ejemplo real de un Sistema de Gestión de Contenidos (CMS).
Siguiendo esta guía, aprenderás:
El código fuente completo para este tutorial está disponible en GitHub.
El Control de Acceso Basado en Roles es más que solo asignar permisos a los usuarios. Se trata de crear un enfoque estructurado para la autorización que equilibre la seguridad con el mantenimiento.
Puedes aprender más sobre Qué es RBAC en Auth Wiki.
Aquí están los principios clave que seguiremos en nuestra implementación:
Los permisos detallados te dan control preciso sobre lo que los usuarios pueden hacer en tu sistema. En lugar de niveles de acceso amplios como "admin" o "usuario", definimos acciones específicas que los usuarios pueden realizar sobre los recursos. Por ejemplo:
read:articles - Ver cualquier artículo en el sistemacreate:articles - Crear nuevos artículosupdate:articles - Modificar artículos existentespublish:articles - Cambiar el estado de publicación de los artículosLa propiedad de recursos es un concepto fundamental en el diseño de autorización de nuestro CMS. Mientras que RBAC define qué acciones pueden realizar diferentes roles, la propiedad agrega una dimensión personal al control de acceso:
update:articles, un autor aún puede editar sus propios artículosEste enfoque de doble capa (roles + propiedad) crea un sistema más intuitivo y seguro. Los editores y administradores aún pueden gestionar todo el contenido a través de sus permisos de rol, mientras que los autores mantienen el control sobre su propio trabajo.
Comencemos diseñando la funcionalidad central de nuestro CMS a través de sus puntos de conexión API:
Para cada punto de conexión, necesitamos considerar dos aspectos del control de acceso:
Así manejaremos el acceso para cada punto de conexión:
| Endpoint | Lógica de control de acceso |
|---|---|
| GET /api/articles | - Cualquiera con permiso list:articles, O autores pueden ver sus propios artículos |
| GET /api/articles/:id | - Cualquiera con permiso read:articles, O autor del artículo |
| POST /api/articles | - Cualquiera con permiso create:articles |
| PATCH /api/articles/:id | - Cualquiera con permiso update:articles, O autor del artículo |
| DELETE /api/articles/:id | - Cualquiera con permiso delete:articles, O autor del artículo |
| PATCH /api/articles/:id/published | - Solo usuarios con permiso publish:articles |
Basándonos en nuestros requisitos de acceso a la API, podemos definir estos permisos:
| Permiso | Descripción |
|---|---|
| list:articles | Ver la lista de todos los artículos en el sistema |
| read:articles | Leer el contenido completo de cualquier artículo |
| create:articles | Crear nuevos artículos |
| update:articles | Modificar cualquier artículo |
| delete:articles | Eliminar cualquier artículo |
| publish:articles | Cambiar el estado de publicación |
Ten en cuenta que estos permisos solo son necesarios cuando accedes a recursos que no son de tu propiedad. Los propietarios de artículos pueden automáticamente:
read:articles)update:articles)delete:articles)Ahora que hemos definido nuestra API y permisos, podemos crear roles que agrupen estos permisos lógicamente:
| Permiso/Rol | 👑 Admin | 📝 Editor | ✍️ Autor |
|---|---|---|---|
| Descripción | Acceso completo al sistema para una gestión total de contenido | Puede ver todos los artículos y controlar el estado de publicación | Puede crear nuevos artículos en el sistema |
| list:articles | ✅ | ✅ | ❌ |
| read:articles | ✅ | ✅ | ❌ |
| create:articles | ✅ | ❌ | ✅ |
| update:articles | ✅ | ❌ | ❌ |
| delete:articles | ✅ | ❌ | ❌ |
| publish:articles | ✅ | ✅ | ❌ |
Nota: Los autores tienen automáticamente permisos de lectura/actualización/eliminación para sus propios artículos, independientemente de los permisos de rol.
Cada rol está diseñado con responsabilidades específicas en mente:
Esta estructura de roles crea una clara separación de responsabilidades:
Antes de comenzar, necesitas crear una cuenta en Logto Cloud, o también puedes utilizar una instancia de Logto auto-hospedada utilizando la versión Logto OSS.
Pero para este tutorial, utilizaremos Logto Cloud para simplicidad.
list:articlesread:articlescreate:articlesupdate:articlespublish:articlesdelete:articles
Ve a Roles en Logto Console para crear los siguientes roles para el CMS
read:articles, list:articles, publish:articlescreate:articles
Ve a la sección de "Gestión de usuarios" en Logto Console para crear usuarios.
En la pestaña "Roles" de los detalles del usuario, puedes asignar roles al usuario.
En nuestro ejemplo, creamos 3 usuarios con los siguientes roles:
Ahora que hemos configurado RBAC en Logto, podemos comenzar a integrarlo en nuestro frontend.
Primero, sigue los Comienzos rápidos de Logto para integrar Logto en tu aplicación.
En nuestro ejemplo, usamos React para demostración.
Después de haber configurado Logto en tu aplicación, necesitamos agregar las configuraciones RBAC para que Logto funcione.
Recuerda cerrar sesión y volver a iniciar sesión para que este cambio surta efecto si ya has iniciado sesión.
Cuando el usuario inicia sesión con Logto y solicita un token de acceso para los recursos de API especificados anteriormente, Logto agregará alcances (permisos) relacionados con el rol del usuario al token de acceso.
Puedes usar getAccessTokenClaims del hook useLogto para obtener los alcances del token de acceso.
Y puedes usar userScopes para verificar si el usuario tiene el permiso para acceder al recurso.
Ahora, es hora de integrar Logto RBAC en tu backend.
Primero, necesitamos agregar un middleware en el backend para verificar los permisos de los usuarios, verificar si el usuario ha iniciado sesión y determinar si tienen los permisos necesarios para acceder a ciertas APIs.
Como puedes ver, en este middleware, verificamos si la solicitud del frontend contiene un token de acceso válido y comprobamos si la audiencia del token de acceso coincide con el recurso API que creamos en Logto Console.
La razón para verificar el recurso API es que nuestro recurso API en realidad representa los recursos de nuestro backend CMS, y todos nuestros permisos de CMS están asociados con este recurso API.
Dado que este recurso API representa los recursos del CMS en Logto, en nuestro código frontend, incluimos el token de acceso correspondiente al realizar solicitudes de API al backend:
Ahora podemos usar el middleware requireAuth para proteger nuestros puntos de conexión de API.
Para APIs que solo deberían ser accesibles para usuarios con permisos específicos, podemos añadir restricciones directamente en el middleware. Por ejemplo, la API de creación de artículos solo debería ser accesible para usuarios con el permiso create:articles:
Para APIs que necesitan verificar tanto permisos como propiedad de recursos, podemos usar la función hasScopes. Por ejemplo, en la API de lista de artículos, los usuarios con el permiso list:articles pueden acceder a todos los artículos, mientras que los autores pueden acceder a sus propios artículos creados:
En este punto, hemos completado la implementación de RBAC. Puedes consultar el código fuente completo para ver la implementación completa.
Ahora, probemos nuestra implementación de RBAC en el CMS utilizando los tres usuarios que acabamos de crear.
Primero, iniciemos sesión como Alex y Charles respectivamente y creemos algunos artículos.
Dado que Alex tiene el rol de Admin, puede crear, eliminar, actualizar, publicar y ver todos los artículos.
Charles, con el rol de Autor, solo puede crear sus propios artículos y solo puede ver, actualizar y eliminar artículos que son de su propiedad.
Bob, con el rol de Editor, puede ver y publicar todos los artículos pero no puede crearlos, actualizarlos o eliminarlos.
¡Felicitaciones! Has aprendido cómo implementar un sistema RBAC robusto en tu aplicación.
Para escenarios más complejos, como construir aplicaciones multi-inquilino, Logto proporciona un soporte organizacional integral. Consulta nuestra guía Construir una aplicación SaaS multi-inquilino: Una guía completa desde el diseño hasta la implementación para aprender más sobre cómo implementar el control de acceso a nivel organizacional.
¡Feliz programación! 🚀