OpenFGA frente a roles fijos: decisión, costo y límite
OpenFGA separa permisos por relación cuando los roles globales quedan grandes. Cómo modelar tuplas, consultar autorización y probar respaldo.
¿Quién puede aprobar una orden cuando cambia de sucursal, proyecto y monto? OpenFGA 1.18.1, publicado el 29 de junio de 2026, modela permisos por relación: usuario, objeto y vínculo verificable en cada consulta. Esta guía compara roles fijos contra autorización relacional y muestra dónde guardar tuplas, cómo consultar permisos, quién administra modelos y cómo probar una salida sin abrir datos de más.
Dónde aparece el rol que deja pasar demasiado
El problema operativo aparece cuando un rol global mezcla tareas que deberían depender del contexto. Un tesorero de una cámara empresaria en San Martín puede aprobar cuotas de socios, ver deuda vencida y exportar reportes, pero no debería cambiar permisos de otra comisión ni leer legajos internos. El objeto visible es una credencial plástica con la palabra administración: ordena la recepción, pero no define permisos por entidad, monto o proyecto. El rol Admin global envejeció. La cifra que corrige la elección viene del repositorio oficial: openfga/openfga registró 5.368 estrellas al chequeo de esta corrida. Esa tracción pública no reemplaza una prueba local, pero ayuda a medir mantenimiento, releases y discusión técnica. OpenFGA 1.18.1 agregó registros de diagnóstico para futuras diferencias de resolución y extendió chequeos experimentales en lote. La referencia global vuelve a la pila de datos. La Stack Overflow Survey 2025 ubicó a PostgreSQL con 55,6 % de uso entre quienes respondieron sobre bases de datos. En un despliegue chico, PostgreSQL puede guardar usuarios, objetos de negocio y auditoría; OpenFGA guarda el modelo de autorización y las tuplas que relacionan persona, recurso y permiso.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, la aplicación identifica usuario, recurso y acción: aprobar, leer, editar o borrar. Segundo, OpenFGA consulta un modelo que define relaciones, por ejemplo socio, tesorero, comisión o expediente. Tercero, el servicio lee tuplas que dicen qué usuario tiene qué relación con qué objeto. Cuarto, responde permitido o rechazado a la aplicación. Quinto, la aplicación registra la decisión con usuario, hora, recurso y resultado. Sexto, backup y prueba de restauración recuperan modelo, tuplas y auditoría. OpenFGA recibe consultas de autorización y entrega una respuesta booleana para cada acción. PostgreSQL guarda registros estructurados, usuarios, estados y auditoría de negocio. Si OpenFGA usa PostgreSQL como datastore, la base también conserva modelos y tuplas del servicio. El monitoreo mide latencia, errores de consulta y cantidad de rechazos inesperados. Un tablero muestra permisos nuevos, permisos removidos y recursos sin dueño. El permiso de administrar modelos queda en IT o seguridad. El permiso de asignar relaciones queda en responsables de área. La aplicación nunca decide sola por un texto de rol; pregunta al servicio y registra la respuesta.
Qué se instala o configura primero
El primer entregable verificable es un modelo pequeño con tres objetos: organización, proyecto y documento. La pila mínima incluye OpenFGA 1.18.1, PostgreSQL 17, migraciones versionadas del modelo, API interna, métricas, backup diario y un set de pruebas de autorización. Una VM de 2 vCPU y 4 GB puede costar entre USD 25 y USD 55 por mes, entre $ 37.750 y $ 83.050 al dólar oficial vendedor de $ 1.510; quedan fuera horas de análisis de roles y cambios en la aplicación. El tiempo razonable es de dos a tres semanas para un primer circuito. UMSA puede usar este enfoque cuando una pyme ya tiene login, pero los permisos dependen de sucursal, proyecto, monto o cliente. La primera entrega debe incluir diez consultas reales, cinco rechazos esperados y una restauración completa del datastore. El costo se controla con una regla escrita: cada permiso nuevo debe nombrar objeto, relación, dueño y fecha de revisión. Si esa información no existe, la tupla queda sin historia operativa.
Dónde se rompe y cómo probarlo
El primer riesgo es el modelo demasiado amplio. La señal aparece cuando una relación permite más acciones que las necesarias. La prueba toma usuarios reales, lista acciones esperadas y ejecuta consultas positivas y negativas. El segundo riesgo es la tupla sin vencimiento operativo. La señal llega cuando un proveedor conserva acceso después de cerrar un trabajo. La prueba crea permisos temporales, revisa fecha de baja y ejecuta un rechazo después del corte. El tercer riesgo es latencia. La señal aparece cuando cada pantalla llama al servicio demasiadas veces. La prueba mide consultas por operación, agrupa chequeos en lote y registra tiempo de respuesta. El cuarto riesgo es respaldo parcial. La señal llega cuando la aplicación restaura usuarios y OpenFGA pierde relaciones. La prueba restaura base de negocio, datastore de autorización y logs en un entorno nuevo, y repite diez consultas conocidas. OpenFGA sirve cuando el equipo acepta modelar permisos como datos revisables. El primer informe útil no dice cuántos roles existen; muestra quién puede hacer qué sobre qué objeto, y desde cuándo.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.