Autorización
En identidad y acceso, la autorización es decidir qué se le permite hacer a una identidad ya autenticada. Va después de que la autenticación haya establecido quién es quien llama, y es una pregunta por petición y no por sesión, porque la respuesta depende del objeto y de la operación concretos que se estén pidiendo.
Qué es la autorización
La autorización es la pieza del control de acceso que determina qué permisos y qué derechos tiene un usuario, un programa o un sistema sobre un recurso digital. Responde a la pregunta «¿qué puedes hacer?», y llega siempre después de la autenticación, que es la que responde «¿quién eres?».
Se apoya en reglas y políticas definidas de antemano, que fijan qué se puede leer, escribir, ejecutar o modificar según la función y las responsabilidades de cada uno. Los mecanismos habituales son las listas de control de acceso (ACL) y el control de acceso basado en roles (RBAC), donde los permisos se agrupan en roles y los roles se asignan a las personas.
Su finalidad es sostener la confidencialidad, la integridad y la disponibilidad de la información: que solo quien tiene la autoridad necesaria pueda interactuar con un activo determinado.
Cómo funciona
La autenticación y la autorización responden a preguntas distintas y fallan de formas distintas. La autenticación pregunta quién eres y ocurre una vez por sesión. La autorización pregunta si puedes hacer esta cosa concreta sobre este objeto concreto, y tiene que ocurrir en cada petición, porque una sesión válida no es un permiso.
En la práctica importan dos dimensiones. La autorización vertical controla qué clase de función puedes invocar: si puedes llegar siquiera a una operación administrativa. La autorización horizontal controla qué instancias de un objeto puedes tocar entre las muchas que tu rol permite en general. La segunda es más difícil, se rompe con más frecuencia y se ve menos, porque en la petición todo parece normal.
Qué sale mal
El fallo es casi siempre una comprobación en la capa equivocada o una comprobación que se fía del contexto que manda el cliente. Deducir el tenant de un campo de la petición en vez de sacarlo de la sesión le entrega la decisión a quien llama. Filtrar bien la vista de lista mientras el manejador del detalle da por hecho que el identificador solo puede haber salido de la lista es el mismo error con un paso de más, y es exactamente lo que describen BOLA e IDOR.
El segundo patrón es la incoherencia entre puntos de entrada. Al mismo objeto se llega por una ruta web, por una versión de la API, por un endpoint de móvil, por una exportación masiva y por un trabajo en segundo plano, y la comprobación está en algunos. Centralizar la decisión lo arregla; reimplementarla en cada manejador garantiza la deriva.
El tercero es confundir los estándares. OAuth es un marco de delegación: decide qué puede pedir una aplicación cliente en nombre de un usuario, y no dice nada sobre si este usuario puede ver este registro. Presentar un token válido como prueba de autorización es un error de categoría que encontramos en APIs de producción con regularidad.
Dónde aparece esto en una auditoría
Pedimos al menos dos cuentas de cada rol, porque la autorización horizontal no se puede demostrar con una. El hallazgo declara la identidad usada, el objeto pedido, la operación, la respuesta y la capa donde debía haberse tomado la decisión. La tabla que compara autenticación y autorización, con los modos de fallo de cada una, vive en la ficha de autenticación para que esté en un solo sitio. Esto forma parte de cómo se prueban las comprobaciones de nivel de objeto y de función en una API.