La autorización determina qué puede hacer una identidad autenticada (usuario, aplicación o servicio) y a qué recursos puede acceder dentro de un sistema.

En la mayoría de los sistemas, la autorización viene después de la autenticación (AuthN). Una vez que el sistema sabe quién es usted, la autorización determina qué puede hacer.

La autorización garantiza que cada identidad autenticada opere dentro de límites definidos. Sin ella, un usuario que iniciara sesión correctamente (AuthN) podría acceder a cualquier dato confidencial y realizar cualquier acción (error de AuthZ). En arquitecturas Zero Trust, las decisiones de autorización se evalúan continuamente durante toda la sesión, no solo en el acceso inicial.

La autorización conecta tres componentes principales:

• Usuarios (identidades autenticadas)
• Permisos (derechos específicos para realizar acciones, como read:Patients)
• Recursos (los activos protegidos)

Control de acceso basado en roles (RBAC)

El RBAC es el modelo básico de autorización. Simplifica la gestión de los permisos asignándolos a roles (por ejemplo, administrador, editor y lector) y, luego, asignando esos roles a los usuarios.

• Cómo funciona: El sistema verifica los roles asignados al usuario y combina sus permisos para determinar si la acción solicitada está permitida.
• Cuándo usarlo: Cuando los permisos del usuario se alinean claramente con funciones o grupos de trabajo estáticos (por ejemplo, en una aplicación empresarial o administrativa típica).
• Limitaciones: El RBAC es menos adecuado para políticas dinámicas o contextuales, como las basadas en dispositivos, hora o ubicación, porque los roles suelen ser estáticos.

Los sistemas de IAM empresariales y los entornos de nube a gran escala implementan el RBAC en todos sus marcos.

Control de acceso basado en atributos (ABAC)

El ABAC emplea políticas dinámicas que evalúan atributos del usuario, el recurso y el entorno para tomar una decisión de acceso.

• Cómo funciona: El acceso se determina mediante expresiones de la política que se evalúan en tiempo real (por ejemplo, user.department == resource.department o la comprobación de si la hora actual está dentro del horario laboral).
• Cuándo usarlo: Cuando las decisiones de autorización son complejas o muy contextuales, o dependen de factores dinámicos (por ejemplo, conceder acceso solo desde un intervalo de IP corporativa, permitir el acceso a documentos solo durante el horario laboral o requerir niveles específicos de autorización de seguridad para recursos confidenciales).
• Contrapartida: Aumenta la complejidad. Las políticas deben diseñarse cuidadosamente y probarse a fondo para evitar conflictos o accesos no intencionados entre las diversas combinaciones de atributos.

Los motores de políticas basados en estándares (como Open Policy Agent o XACML) hacen cumplir las políticas del ABAC para mantener la uniformidad y facilitar las auditorías.

Control de acceso basado en relaciones (ReBAC) y autorización granular (FGA)

El ReBAC basa la autorización en las relaciones y la propiedad entre un usuario y un recurso específico.

• Cómo funciona: El sistema comprueba relaciones explícitas (por ejemplo, “propiedad de”, “compartido con”, “miembro del grupo”) para conceder o negar acceso. Las implementaciones actuales usan modelado de relaciones basado en grafos para navegar cadenas de permisos complejas.
• Cuándo usarlo: En sistemas colaborativos, como redes sociales o plataformas de uso compartido de documentos (por ejemplo, “solo el propietario de la publicación puede eliminarla”, “los usuarios en espacios de trabajo compartidos pueden ver todos los documentos”).

Los sistemas de ReBAC y FGA aprovechan las infraestructuras que detectan las relaciones y los patrones de autorización basados en grafos para modelar estas relaciones y hacer consultas sobre ellas a gran escala. Numerosas implementaciones de código abierto (como OpenFGA y SpiceDB) hacen que esta tecnología sea accesible para todos los desarrolladores.

La autorización detallada (FGA) amplía los principios del ReBAC para habilitar decisiones de autorización basadas en grafos de relaciones complejas a gran escala. Los sistemas de FGA pueden responder preguntas como “¿Puede el usuario X editar el documento Y?” recorriendo las relaciones entre grupos, organizaciones y permisos anidados. Este modelo posibilita la autorización en la colaboración de documentos y las plataformas sociales, donde el acceso puede heredarse mediante jerarquías de carpetas, membresías de grupos y relaciones compartidas.

Las aplicaciones basadas en API hacen cumplir la autorización mediante tokens de acceso emitidos a través del flujo de autorización de OAuth 2.0.

1. Asignación de autorizaciones: Tras la autenticación exitosa, el servidor de autorización determina los permisos concedidos al usuario en función del modelo de AuthZ elegido y de cualquier política dinámica que corresponda (por ejemplo, RBAC o ABAC).
2. Emisión de tokens: El servidor emite un token de acceso, comúnmente un token web JSON (JWT), que contiene atributos sobre el sujeto y sus ámbitos autorizados, o emite un token opaco que requiere validación a través del extremo de introspección del servidor de autorización. El flujo de autenticación determina cómo se adquieren los tokens y qué atributos contienen.
3. Implementación de la API: Cuando una API recibe una solicitud, valida el JWT y aplica las reglas de autorización según los atributos dentro del token.

Este enfoque basado en tokens es un enfoque sin estado. El token contiene todo lo que la API necesita: el contexto de autorización y una firma criptográfica.

Los ámbitos definen los permisos que solicita una aplicación cliente al servidor de autorización. El servidor de autorización otorga únicamente los ámbitos para los que el usuario dio su consentimiento y los incluye en el token de acceso emitido.

• Cuando una aplicación solicita un token de acceso, especifica los ámbitos que necesita (por ejemplo, read:documents o write:documents).
• El servidor de autorización compara los ámbitos solicitados con los permisos reales del usuario y concede acceso solo a aquello para lo que el usuario tiene autorización.
• El token de acceso emitido contiene los ámbitos aprobados. La API valida que el token contenga los ámbitos requeridos para la operación solicitada; si el token carece del ámbito necesario, la API niega el acceso.

Los roles suelen definir conjuntos de acceso amplios, mientras que los ámbitos representan permisos detallados a nivel de acción. Combinar los roles y los ámbitos ofrece flexibilidad para las API.

OpenID Connect (OIDC) amplía OAuth 2.0 al permitir la emisión de tokens de identificación para verificar la identidad del usuario y para los atributos de perfil, además de los ámbitos de autorización.

Cada extremo de API protegido debe validar el token de acceso recibido, es decir, debe verificar la firma del token (ayuda a garantizar la integridad y autenticidad), el vencimiento (atributo exp), el público (atributo aud), el emisor (atributo iss) y los permisos requeridos (ámbitos o roles). La validación adicional puede incluir comprobar el estado de revocación del token, validar el atributo nbf (no válido antes de) y aplicar los límites de frecuencia por cliente. Para los JWT, los servidores de autorización publican claves públicas a través del extremo del conjunto de claves web JSON (JWKS) para la verificación de firmas.

Las API deben devolver códigos de estado HTTP específicos para comunicar el tipo de error.

• 401 - No autorizado: Significa que la autenticación falló o no existe. La solicitud carece de credenciales válidas (el token falta, es inválido o caducó).
  Ejemplos: Falta el encabezado de autorización, JWT caducado, firma inválida.
• 403 - Prohibido: Significa que la autorización falló. La identidad del usuario es conocida (fue autenticado), pero sus permisos rechazan el acceso al recurso o la acción solicitados.
  Ejemplo: El token es válido, pero el usuario no tiene rol de administrador para DELETE/users/:id, por lo que el ámbito es insuficiente para la operación solicitada.

¿Cuál es el riesgo de seguridad si las verificaciones de autorización no son uniformes?

Cuando la lógica de autorización está dispersa por todo el código, algunos procesos pueden fallar a la hora de hacer cumplir las verificaciones requeridas y dejar al descubierto vulnerabilidades que los atacantes pueden aprovechar. Centralizar la aplicación de autorizaciones mediante middleware o un motor de políticas es la práctica recomendada. Los enfoques nuevos incluyen la política como código, que emplea lenguajes como Rego (Open Policy Agent) para separar la lógica de autorización del código de la aplicación y permitir pruebas y auditorías centralizadas.

¿Qué es el principio de privilegio mínimo?

Este principio obliga a conceder a los usuarios o servicios solo los roles y permisos mínimos necesarios para su trabajo, minimizando así el daño potencial de una identidad vulnerada. En la práctica, esto implica auditar los permisos con frecuencia, implementar concesiones de acceso con plazos definidos y eliminar roles o ámbitos no utilizados.

¿Cuándo debo usar la autenticación escalonada?

La autenticación escalonada equilibra la seguridad y la facilidad de uso. Solo le pide factores adicionales (como un escaneo biométrico) a un usuario ya autenticado cuando intenta realizar una operación de alto riesgo, como una transferencia bancaria o una modificación de nómina. Este enfoque también se denomina autenticación adaptativa o contextual.

¿Cuál es una vulnerabilidad de autorización habitual?

La autorización a nivel de objeto defectuosa (BOLA), también conocida como referencia directa a un objeto insegura (IDOR), es una vulnerabilidad común. Ocurre cuando una API comprueba un permiso general (por ejemplo, “puede leer un documento”), pero no verifica que el usuario tenga acceso al identificador correspondiente al recurso solicitado (por ejemplo, “identificador de documento 12345”). Esta vulnerabilidad se sitúa casi siempre como API1:2023 entre las diez vulnerabilidades de la clasificación OWASP API Security Top 10. Es necesario validar siempre el permiso de acción y el acceso a nivel de recurso.

¿Cuál es la diferencia entre autorización y control de acceso?

La autorización es un componente del control de acceso. El control de acceso es la disciplina de seguridad más amplia y abarca la autenticación (verificación de identidad), la autorización (concesión de permisos) y la aplicación (garantizar que se cumplan las políticas). La autorización se refiere explícitamente a la toma de decisiones y a la aplicación de lo que puede hacer una identidad autenticada.

¿Cómo funciona la autorización en las arquitecturas de microservicio?

Los sistemas distribuidos hacen cumplir la autorización en varias capas: API gateway (general), malla de servicios (a nivel de red) o servicios individuales (detallada). La autorización basada en tokens con JWT permite la verificación sin estado entre servicios. Sin embargo, mantener la uniformidad es un desafío. Las actualizaciones de políticas deben alcanzar a todos los servicios, y las decisiones basadas en relaciones requieren un motor de políticas centralizado o almacenamiento en caché distribuido.

La autorización es un componente de una estrategia integral de gestión de identidades y accesos. Los marcos de autorización modernos, como OAuth 2.0 y OpenID Connect, junto con modelos detallados, como ABAC, ReBAC y la autorización detallada (FGA), permiten a los desarrolladores crear aplicaciones más seguras y escalables que se alineen con los principios de Zero Trust. Para obtener más información sobre autenticación, modelos de control de acceso y prácticas de seguridad recomendadas, consulte la serie de Introducción a IAM de Auth0.

Más información

Estos materiales tienen únicamente fines informativos generales. Usted es responsable de obtener orientación de seguridad, de privacidad, de cumplimiento o empresarial de sus propios asesores profesionales, y no debe confiar solamente en la información suministrada aquí.