RBAC en práctica: Implementando una autorización segura para tu aplicación
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.
Developer
¿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:
- ✨ Cómo diseñar e implementar permisos detallados que te proporcionen un control preciso
- 🔒 Mejores prácticas para organizar permisos en roles significativos
- 👤 Técnicas para manejar eficazmente la propiedad de recursos
- 🚀 Maneras de hacer tu sistema de autorización escalable y mantenible
- 💡 Implementación práctica usando un ejemplo de CMS del mundo real
El código fuente completo para este tutorial está disponible en GitHub.
Entendiendo los fundamentos de RBAC
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:
Diseño de permisos detallados
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ículos
Propiedad de recursos y control de acceso
La 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:
- Los autores tienen automáticamente acceso a los artículos que crearon
- Este modelo de propiedad natural significa que los autores siempre pueden ver y editar su propio contenido
- El sistema verifica tanto permisos de rol O propiedad al manejar operaciones de artículos
- Por ejemplo, incluso sin el permiso
update:articles, un autor aún puede editar sus propios artículos - Este diseño reduce la necesidad de permisos de rol adicionales mientras mantiene la seguridad
Este 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.
Diseñando APIs seguras
Comencemos diseñando la funcionalidad central de nuestro CMS a través de sus puntos de conexión API:
Implementar control de acceso para tu API
Para cada punto de conexión, necesitamos considerar dos aspectos del control de acceso:
- Propiedad de recursos - ¿El usuario es dueño de este recurso?
- Permisos basados en roles - ¿El rol del usuario permite esta operación?
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 |
Creando un sistema de permisos que escale
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:
- Ver sus propios artículos (no se necesita
read:articles) - Editar sus propios artículos (no se necesita
update:articles) - Eliminar sus propios artículos (no se necesita
delete:articles)
Construyendo roles efectivos
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:
- Admin: Tiene control completo sobre el CMS, incluyendo todas las operaciones de artículos
- Editor: Se enfoca en la revisión de contenido y gestión de publicación
- Autor: Se especializa en la creación de contenido
Esta estructura de roles crea una clara separación de responsabilidades:
- Los autores se enfocan en crear contenido
- Los editores gestionan la calidad y visibilidad del contenido
- Los administradores mantienen el control general del sistema
Configurar RBAC en Logto
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.
Configurando tu aplicación
- Ve a "Aplicaciones" en Logto Console para crear una nueva aplicación react
- Nombre de la aplicación: Sistema de Gestión de Contenidos
- Tipo de aplicación: Aplicación Web Tradicional
- URIs de redirección: http://localhost:5173/callback
Configurando recursos de API y permisos
- Ve a "Recursos de API" en Logto Console para crear un nuevo recurso de API
- Nombre de la API: API del CMS
- Identificador de la API: https://api.cms.com
- Agrega permisos al recurso de API
list:articlesread:articlescreate:articlesupdate:articlespublish:articlesdelete:articles
Creando roles
Ve a Roles en Logto Console para crear los siguientes roles para el CMS
- Admin
- con todos los permisos
- Editor
- con
read:articles,list:articles,publish:articles
- con
- Autor
- con
create:articles
- con
Asignando roles a usuarios
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:
- Alex: Admin
- Bob: Editor
- Charlie: Autor
Integrar tu frontend con Logto RBAC
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.
Integrar tu backend con Logto RBAC
Ahora, es hora de integrar Logto RBAC en tu backend.
Middleware de autorización en el 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.
Protegiendo 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.
Probar la implementación de RBAC en el CMS
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.
Conclusión
¡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! 🚀