En junio incorporamos una capa de identidad a las aplicaciones que genera OwlMeans.
La pantalla de inicio de sesión era la parte visible. Detrás había cuentas, sesiones, permisos y una separación entre quienes usan nuestra plataforma y quienes usan la app de un cliente.
Quería que esas decisiones formaran parte de la arquitectura de la aplicación desde el principio.
Cuentas e inicio de sesión
Un inicio de sesión que sale bien le dice a la aplicación quién ha llegado. No resuelve qué puede leer o cambiar esa persona.
Un cliente puede necesitar un usuario que vea sus propios registros, un operador que vaya despachando una cola de trabajo y un administrador que gestione los accesos. Son responsabilidades distintas, aunque las pantallas se parezcan.
La explicación de OpenID Connect que publica la OpenID Foundation describe el protocolo de identidad. Los permisos los siguen determinando las reglas de negocio de la aplicación.
Lo que hicimos en junio conectó el flujo de inicio de sesión con la app generada y aportó una forma común de representar el acceso. Así, el resto del código tenía una base coherente sobre la que apoyarse.
Lo que no hizo fue decidir la política de cada cliente en su lugar.
La implementación usaba credenciales de un solo uso enviadas por correo electrónico para los usuarios finales de las apps. Con eso se evitaba un flujo aparte de gestión de contraseñas en la aplicación generada.
No presentaría el inicio de sesión por correo como una garantía general de seguridad, ni lo pondría al mismo nivel que los métodos de autenticación más fuertes.
Todavía hay que pensar en la entrega del correo, en la recuperación de cuentas y en el comportamiento de las sesiones. Y también en cómo una persona pasa a ser miembro de la organización de un cliente.
Son detalles que se escapan con facilidad si la única comprobación de aceptación es que el formulario de inicio de sesión se envíe.
Los límites del acceso
El modelo de permisos era la parte que no quería dejar en manos de decisiones improvisadas y dispersas.
Una pantalla puede tener un requisito de acceso, pero la operación que hay debajo también necesita uno que se haga cumplir. Ocultar un botón no es una regla de autorización.
La guía rápida de autorización de OWASP recomienda definir los límites del acceso, denegarlo por defecto y comprobar los permisos en las peticiones. También pide probar esas reglas.
En la estructura de nuestras aplicaciones, el requisito se declara con las convenciones de acceso del framework. El código de negocio debería usar esas convenciones de forma coherente, en lugar de inventarse una interpretación distinta en cada manejador.
En una herramienta de trabajo corriente, yo probaría las distinciones reales. Un usuario puede ver su registro. Un operador puede tramitar una solicitud que tiene asignada. Ninguno de los dos debería obtener acceso de administrador solo por haber iniciado sesión.
Ese comportamiento tiene que estar en los requisitos del producto y en las pruebas. El nombre de un protocolo no basta para garantizarlo.
OwlMeans tiene sus propias cuentas. Una app creada con OwlMeans tiene usuarios finales. Mantener separadas esas dos cosas formó parte del trabajo de identidad.
Los límites entre clientes, proyectos y recursos importan porque una identidad puede ser válida y, aun así, no tener autoridad sobre una acción concreta. Un identificador de usuario, por sí solo, no es suficiente para expresar todos esos límites.
El entorno de producción también necesita la configuración de inicio de sesión prevista para él. No hay que dar por hecho que las cuentas y las direcciones de redirección que se usan en la vista previa sean la configuración de producción.
En la práctica, la pregunta es si la persona adecuada puede completar el flujo de trabajo previsto y si a quien queda fuera de ese límite se le deniega el acceso.
OIDC y la entrega
OIDC le da a la aplicación una interfaz de identidad estándar. No demuestra que estén disponibles todas las integraciones con sistemas de identidad empresariales, que se hayan probado todos los límites entre inquilinos ni que quede respondido el cuestionario de seguridad de un comprador.
La versión anterior de este artículo lo hacía sonar demasiado automático.
Una integración sigue dependiendo del proveedor y de la configuración. Los roles de un cliente y las reglas de su organización todavía hay que especificarlos. Y revisar la aplicación generada sigue formando parte de la entrega.
Prefiero describir las piezas que tenemos antes que dar a entender una certificación por haber elegido un protocolo.
En agosto, el sistema de identidad integrado pasó a ser la única implementación de IAM de la Plataforma. Lo que se planteaba en junio sobre un backend externo intercambiable ya solo tiene valor histórico.
El trabajo actual sobre el acceso también distingue los controles ya implementados de las mejoras que siguen en desarrollo. La documentación y el código aportan pruebas del mecanismo, pero no pueden demostrar que toda aplicación construida con él sea segura.
La guía actual de autenticación explica las piezas que ofrece el framework. El diseño del acceso de cada aplicación hay que comprobarlo en el contexto del producto que se está construyendo.
Integrar la identidad significa que esa parte del sistema la mantenemos nosotros. Los clientes todavía tienen que describir las personas, los recursos y las acciones que necesita su producto. Tenemos una forma común de expresar esas reglas. Comprobarlas sigue siendo parte del trabajo.
Revisado el 15 de octubre de 2026. Se mantiene la historia de la implementación de junio y se corrigen las comparaciones de precios anteriores y las promesas genéricas sobre uso empresarial y seguridad.