Tema 16
A medida que una organización crece, identidad y acceso dejan de ser una función aislada dentro de cada aplicación y pasan a formar parte de una arquitectura compartida. En ese escenario aparecen componentes especializados como los identity providers, los authorization servers, los directorios, los motores de políticas y los sistemas de aprovisionamiento. Entender cómo se relacionan evita diseños confusos, dependencias innecesarias y controles mal ubicados.
Muchas organizaciones empiezan resolviendo autenticación y autorización dentro de cada sistema por separado. Al principio parece simple: cada aplicación mantiene sus usuarios, sus contraseñas y sus permisos. Pero a medida que aumenta la cantidad de aplicaciones, usuarios, APIs y socios externos, ese enfoque se vuelve difícil de operar y aún más difícil de asegurar.
Una solución IAM busca centralizar o coordinar capacidades clave: identidad, autenticación, emisión de tokens, políticas de acceso, ciclo de vida de cuentas, auditoría e integración con sistemas internos y externos. Eso no significa que todo deba vivir en un único componente, sino que cada pieza debe tener una responsabilidad clara.
Una arquitectura IAM, o Identity and Access Management, es el conjunto de componentes, flujos, integraciones y reglas que permiten gestionar identidades y controlar acceso en forma consistente dentro de una organización.
Su propósito no es únicamente “hacer login”. También debe responder preguntas como:
Un Identity Provider, o IdP, es el componente que autentica identidades y emite una representación confiable de ese resultado hacia otras aplicaciones o servicios. En términos prácticos, es quien confirma “esta identidad fue autenticada bajo estas condiciones”.
El IdP suele encargarse de procesos como login, MFA, recuperación de cuenta, federación con terceros, sesión central y entrega de atributos básicos de identidad. En muchos entornos modernos, además, expone flujos basados en OIDC o SAML para que otras aplicaciones deleguen la autenticación.
Esto no significa que el IdP deba decidir por sí mismo toda autorización de negocio. Su responsabilidad principal gira alrededor de identidad autenticada y confianza entre sistemas.
El Authorization Server es el componente que emite tokens de acceso y administra condiciones de delegación, alcance y vigencia. En el mundo OAuth 2.0 y OpenID Connect, este rol es central porque define cómo un cliente obtiene credenciales temporales para acceder a recursos protegidos.
Según la plataforma, el IdP y el Authorization Server pueden estar integrados en el mismo producto o separarse conceptualmente. Lo importante es no perder de vista sus responsabilidades: el IdP gira más alrededor de autenticación e identidad; el Authorization Server, alrededor de emisión y gestión de tokens para acceso delegado o directo.
En muchas implementaciones comerciales un mismo producto cumple ambos papeles. Eso puede llevar a pensar que son sinónimos, pero conceptualmente no lo son.
Una forma simple de diferenciar:
La distinción importa porque ayuda a diseñar mejor integraciones, a entender los límites de cada token y a no trasladar decisiones de acceso a componentes equivocados.
Otro error habitual es llamar “IdP” a cualquier repositorio de usuarios. Un directorio de identidad, como vimos en temas anteriores, almacena información sobre cuentas, grupos y atributos. Pero almacenar identidad no equivale a autenticarla ni a emitir tokens.
En una arquitectura madura suele haber varias capas:
Estas capas pueden convivir en una misma plataforma o distribuirse entre varias soluciones.
Una solución IAM empresarial suele incluir varios de estos elementos:
No todas las organizaciones necesitan el mismo nivel de complejidad, pero sí necesitan claridad sobre qué problema resuelve cada bloque.
En un escenario típico, una aplicación redirige al usuario hacia un IdP para que allí se produzca la autenticación. El IdP valida credenciales, puede requerir MFA, resuelve políticas de riesgo y, si todo es correcto, devuelve una afirmación o tokens al cliente según el protocolo utilizado.
La ventaja es que la autenticación queda centralizada y las aplicaciones ya no necesitan gestionar directamente contraseñas, MFA o integración con múltiples fuentes de identidad. Eso mejora consistencia, experiencia de usuario y capacidad de gobierno.
Cuando el escenario involucra APIs, el cliente obtiene un access token emitido por un Authorization Server. Luego presenta ese token ante la API, que valida su autenticidad, su vigencia y su alcance. Después de esa validación técnica, la API debe aplicar su lógica propia de autorización sobre el recurso solicitado.
Esto implica que la arquitectura IAM no reemplaza completamente a la aplicación. El sistema central puede autenticar, emitir tokens y aportar contexto, pero la autorización fina sobre objetos y acciones de negocio sigue perteneciendo al servicio que protege el recurso.
En una arquitectura IAM bien pensada, la decisión de acceso puede repartirse en distintos niveles:
Intentar resolver todo en un único lugar suele fallar. Si se centraliza demasiado, el sistema IAM termina cargando lógica de negocio que no le corresponde. Si se descentraliza por completo, se pierde consistencia y control.
| Enfoque | Fortaleza principal | Desafío principal |
|---|---|---|
| Centralizado | Consistencia y gobierno más simple | Punto crítico de dependencia y posible rigidez |
| Federado | Integración entre dominios y organizaciones | Mapeo de confianza y atributos más complejo |
| Híbrido | Equilibrio entre control central y realidades heterogéneas | Mayor esfuerzo de diseño y operación |
La mayoría de las organizaciones reales terminan en esquemas híbridos: algún grado de centralización interna combinado con federación hacia terceros, SaaS o ambientes legacy.
Una solución IAM moderna no administra solo empleados o clientes. También debe contemplar cuentas técnicas, aplicaciones, microservicios, agentes automatizados y claves de acceso entre sistemas. Esto cambia el diseño de la arquitectura porque no todos los sujetos siguen el mismo flujo.
Las identidades humanas requieren onboarding, MFA, recuperación de cuenta y experiencia de login. Las no humanas requieren emisión controlada de secretos, credenciales efímeras, rotación, acotación de privilegios y trazabilidad clara de qué sistema actuó y por qué.
Una arquitectura IAM no está completa si solo autentica usuarios. También debe estar conectada con el ciclo de vida de identidades: altas, cambios, bajas, transferencias, privilegios temporales y revisiones periódicas.
Si un empleado cambia de área o deja la organización, la solución IAM debería reflejar ese cambio en directorios, grupos, aplicaciones federadas y accesos derivados. De lo contrario, la autenticación centralizada convive con permisos obsoletos, que en la práctica siguen siendo una falla de seguridad.
En IAM no alcanza con decidir acceso; también es necesario poder demostrar cómo y por qué se decidió. Por eso una arquitectura robusta registra eventos como autenticaciones exitosas y fallidas, desafíos MFA, emisión de tokens, consentimientos, elevaciones de privilegio y cambios en políticas o grupos.
Sin esa capa de observabilidad, la organización pierde capacidad de investigación, cumplimiento y mejora continua. La auditoría no es un agregado administrativo: es una parte estructural del control de acceso moderno.
Diseñar una solución IAM exige pensar en componentes, pero sobre todo en límites claros entre ellos. Cuando el proveedor de identidad, el servidor de autorización, el directorio y las aplicaciones entienden bien su papel, el ecosistema gana seguridad, mantenibilidad y capacidad de escalar. Cuando esos roles se mezclan, aparecen integraciones frágiles, permisos mal ubicados y diagnósticos difíciles.
En el próximo tema nos enfocaremos en los riesgos y ataques más comunes del dominio de identidad y acceso, para ver cómo estas arquitecturas son puestas a prueba en escenarios reales.