Cómo las Aplicaciones Modernas Gestionan Roles y Permisos

Tu usuario puede ver un documento. ¿Pero puede compartirlo? ¿Puede compartirlo con cualquiera, o solo dentro de su organización? ¿Puede revocar el acceso que otorgó? Estas preguntas exponen por qué el control de acceso basado en roles tradicional falla en las aplicaciones modernas.

Los roles estáticos como “admin”, “editor” y “viewer” funcionaban cuando las aplicaciones eran más simples. Los productos SaaS colaborativos y multi-tenant de hoy necesitan algo más flexible. Este artículo explica cómo los patrones de autorización modernos resuelven estos desafíos y por qué la industria ha evolucionado más allá del pensamiento basado únicamente en roles hacia la autorización granular.

Por Qué el RBAC Tradicional Se Queda Corto

El Control de Acceso Basado en Roles (RBAC, por sus siglas en inglés) asigna permisos a través de roles. Un usuario obtiene el rol “editor”, que otorga un conjunto predefinido de permisos. Simple e intuitivo.

El problema surge a medida que las aplicaciones crecen. Considera una herramienta de gestión de proyectos donde los usuarios necesitan diferentes niveles de acceso por proyecto, por espacio de trabajo y por tipo de documento. Comienzas a crear roles como “project-A-editor” y “workspace-B-admin”. Esta explosión de roles hace que el sistema sea inmanejable.

El RBAC también tiene dificultades con preguntas basadas en relaciones. “¿Puede este usuario editar este documento?” depende de si es su propietario, si alguien lo compartió con él, o si pertenece a un equipo que tiene acceso. Los roles estáticos no pueden expresar estas condiciones de manera elegante.

Patrones de Autorización Modernos

Control de Acceso Basado en Relaciones (ReBAC)

ReBAC determina el acceso a través de relaciones entre entidades. En lugar de preguntar “¿tiene este usuario el rol de editor?”, preguntas “¿tiene este usuario una relación de editor con este documento?”

El sistema Zanzibar de Google fue pionero en este enfoque a gran escala. Cuando compartes un Google Doc, estás creando una relación. El sistema luego recorre estas relaciones para responder preguntas sobre permisos. Herramientas como OpenFGA, SpiceDB y Permify implementan modelos inspirados en Zanzibar para aplicaciones de cualquier tamaño.

ReBAC maneja escenarios colaborativos de forma natural. Compartir, membresía de equipos y jerarquías organizacionales se convierten en conceptos de primera clase en lugar de soluciones improvisadas con roles.

Control de Acceso Basado en Atributos (ABAC)

ABAC evalúa el acceso basándose en atributos de usuarios, recursos y contexto. Una política podría establecer: “los usuarios pueden acceder a documentos si su departamento coincide con el departamento del documento y la solicitud ocurre durante horas laborales”.

Este modelo sobresale en reglas dependientes del contexto. Las aplicaciones de salud usan ABAC para hacer cumplir requisitos HIPAA—el acceso depende de la relación paciente-proveedor, la sensibilidad de los datos y el contexto de acceso.

RBAC vs ReBAC: Cuándo Usar Cada Uno

RBAC sigue siendo apropiado para aplicaciones con límites de permisos claros y estáticos. Las herramientas internas con tipos de usuario bien definidos se benefician de su simplicidad.

ReBAC se adapta mejor cuando los permisos dependen de la propiedad del recurso, el compartir o la estructura organizacional. Cualquier aplicación con funcionalidad de “compartir” o multi-tenancy debería considerar ReBAC.

La mayoría de los sistemas en producción combinan ambos. RBAC maneja categorías amplias (admin vs. usuario regular), mientras que ReBAC gestiona permisos a nivel de recurso.

Patrones Arquitectónicos para Control de Acceso en Aplicaciones Web

Separar Autenticación de Autorización

La autenticación responde “¿quién es este usuario?” La autorización responde “¿qué puede hacer?” Las arquitecturas modernas tratan estos como asuntos separados con servicios dedicados para cada uno.

Tu proveedor de identidad maneja la autenticación. Un servicio de autorización separado—ya sea construido internamente o gestionado—maneja las decisiones de permisos. Esta separación permite que cada sistema evolucione independientemente.

Política como Código

Los patrones de autorización modernos favorecen expresar reglas como código en lugar de configuraciones de base de datos. Política como código significa que tu lógica de autorización vive en control de versiones, se revisa en pull requests y se despliega a través de tu pipeline estándar.

Open Policy Agent (OPA) usa Rego para definiciones de políticas. Cedar, desarrollado por AWS, proporciona otro lenguaje de políticas. Estas herramientas hacen que la lógica de autorización sea testeable y auditable.

Política Centralizada, Aplicación Distribuida

El patrón que escala: define políticas centralmente, aplícalas en cada servicio. Tu motor de políticas mantiene las reglas. Cada microservicio consulta al motor para decisiones de permisos, a menudo almacenando en caché los resultados para rendimiento.

Esta arquitectura mantiene la autorización consistente entre servicios mientras evita un punto único de falla.

Implicaciones en el Frontend

El backend sigue siendo la fuente de verdad para todas las decisiones de permisos. Nunca confíes en el frontend para seguridad.

Dicho esto, los frontends necesitan información de permisos para una buena UX. El feature gating—ocultar botones que los usuarios no pueden hacer clic, deshabilitar formularios que no pueden enviar—requiere conocer los permisos del lado del cliente. El patrón es directo: usa verificaciones de permisos (por ejemplo, “¿puede este usuario realizar esta acción?”) para decisiones de UI, pero siempre valida en el servidor.

Bibliotecas como CASL ayudan a gestionar la lógica de permisos del lado del cliente mientras mantienen la aplicación real del lado del servidor.

Conclusión

La autorización granular no es experimental—es cómo funcionan las aplicaciones modernas. Google, GitHub y Notion todos usan modelos basados en relaciones. Los motores de políticas impulsan la autorización en empresas de todos los tamaños.

Comienza identificando dónde tu RBAC actual tiene dificultades. Si estás creando roles para cada combinación de permisos, o si compartir y colaborar se sienten como añadidos, los patrones de autorización modernos simplificarán tu sistema mientras lo hacen más capaz.

El cambio de “¿qué rol tiene este usuario?” a “¿qué relación tiene este usuario con este recurso?” cambia cómo piensas sobre los permisos. Es un mejor modelo mental para cómo los usuarios realmente interactúan con las aplicaciones modernas.

Preguntas Frecuentes

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.