La autenticación verifica una identidad; la autorización determina el acceso a una acción o recurso. En una aplicación SaaS, comprobar las credenciales de Laura permite establecer qué cuenta hace una petición. Decidir si esa cuenta puede desactivar a un compañero exige otra comprobación contra las reglas de acceso del producto.
La distinción afecta a la especificación de una funcionalidad. Los métodos de inicio de sesión, su gestión y la autenticación multifactor se relacionan con las evidencias utilizadas para establecer la identidad. Los roles, la pertenencia a una empresa y la propiedad de un registro determinan a qué puede acceder una cuenta identificada. Iniciar sesión correctamente deja pendientes esas decisiones sobre permisos.
Roles y acciones en un espacio compartido
Pensemos en un producto hipotético de gestión de proyectos con los roles Owner, Admin y Member. Los miembros pueden crear tareas y comentar proyectos; los administradores pueden invitar y desactivar usuarios; la persona propietaria puede eliminar la cuenta. Los tres roles pueden iniciar sesión, pero tienen atribuciones distintas dentro del espacio de trabajo.
Esas etiquetas son un punto de partida. El equipo aún debe decidir si un administrador puede desactivar a otro, si alguien puede cambiar su propio rol y cómo se transfiere la propiedad cuando se marcha la persona responsable. Estas decisiones afectan a la recuperación de cuentas, a los procedimientos de soporte y al riesgo de dejar un espacio sin nadie que pueda gestionarlo.
Un cambio de permisos también afecta al trabajo en curso. Si un administrador pierde el acceso a exportaciones mientras se prepara un archivo, el producto necesita una regla para decidir si continúa ese trabajo y si el archivo puede descargarse. Ingeniería podrá implementar las comprobaciones cuando esté claro el comportamiento esperado.
La autorización se aplica a recursos concretos
Un rol que permite consultar facturas no determina qué facturas puede consultar la cuenta. Laura podría tener acceso a las de la empresa A y carecer de acceso a los registros de la empresa B. En un producto multiempresa, donde varias organizaciones comparten la aplicación, ese límite debe aplicarse a cada operación pertinente.
Cambiar un identificador en una URL o petición no debe permitir acceder a la factura de otra empresa. Ocultar un enlace en la interfaz es insuficiente: el servidor que atiende la petición debe comprobar el acceso al recurso solicitado. Límites similares se aplican a proyectos, registros de clientes, informes y claves de API.
Algunas reglas dependen del contexto además del rol. Una organización podría permitir a sus miembros editar proyectos propios y reservar los cambios de facturación a la persona propietaria. Documentar la acción, el recurso y las condiciones ofrece un criterio de revisión más preciso que una afirmación amplia como «los administradores tienen acceso».
Cómo especificar una exportación
Un botón para exportar usuarios muestra cómo las reglas de acceso forman parte de una funcionalidad. La especificación debe establecer qué roles pueden solicitar la exportación, de qué organización serán los registros y qué campos aparecerán. La divulgación de datos personales, información de facturación o credenciales tiene consecuencias distintas.
La interfaz debe reflejar esas reglas y la operación debe aplicarlas. Las pruebas pueden comprobar peticiones permitidas y rechazadas: un administrador autorizado que exporta su empresa, un miembro que intenta la misma operación y un administrador que pide registros de otra empresa. Los cambios de permisos durante una sesión también necesitan un resultado definido.
Estos casos revelan dudas fáciles de pasar por alto en el diseño de una pantalla. También dan a Producto, Ingeniería y Seguridad una base compartida para revisar si la implementación respeta el modelo de acceso previsto.
Revisar el acceso con Ingeniería
En una funcionalidad con cuentas o acciones sensibles conviene documentar cómo se identifica a quien hace la petición, qué solicita y en qué condiciones debe permitirse. Hay que incluir casos representativos que deban rechazarse. Así pueden revisarse los mecanismos de autenticación junto con las comprobaciones de autorización que los acompañan.
El libro Seguridad para Product Managers desarrolla el control de acceso junto con otras decisiones de seguridad del trabajo de producto. La guía de autorización de OWASP ofrece una referencia técnica para revisar estas comprobaciones.
