Tema 8
En arquitecturas distribuidas la confianza depende de identidades verificables. Usuarios, APIs, servicios, jobs y componentes de plataforma necesitan demostrar quiénes son y operar con permisos acotados. Sin un modelo claro de identidad y autorización, la arquitectura pierde trazabilidad y se vuelve difícil de proteger.
Una de las preguntas más importantes en una arquitectura segura es simple: quién está actuando. La respuesta, sin embargo, no siempre es simple. En sistemas distribuidos puede haber usuarios humanos, clientes externos, APIs consumidoras, microservicios internos, jobs temporales, procesos de integración y componentes de infraestructura.
Cada uno de estos actores necesita algún tipo de identidad y algún conjunto de permisos. Si esas identidades no están bien definidas o si los permisos se asignan de forma amplia y opaca, aparecen problemas de trazabilidad, abuso interno, escalada de privilegios y dificultades para contener incidentes.
Este tema se centra en cómo se construye identidad verificable en microservicios, cómo funciona la autenticación federada y cómo se toman decisiones de autorización entre servicios sin depender de confianza implícita.
No todas las identidades representan personas. En arquitecturas modernas también existen identidades técnicas: servicios, contenedores, pods, tareas automatizadas, pipelines o integraciones de terceros que actúan sin intervención humana directa.
| Tipo de identidad | Ejemplos | Riesgo principal si se gestiona mal |
|---|---|---|
| Humana | Usuarios finales, administradores, operadores | Suplantación, abuso de cuenta, errores operativos |
| Técnica | Servicios, jobs, integraciones, agentes | Permisos excesivos, baja trazabilidad, movimiento lateral |
| Federada | Identidades provenientes de proveedores externos | Confianza mal delegada o claims mal interpretados |
Una arquitectura madura trata ambos tipos con rigor, pero distinguiendo claramente sus necesidades y riesgos.
Autenticación es el proceso por el cual un actor demuestra su identidad. La pregunta que responde es: quién sos. En microservicios esta validación puede ocurrir en el borde, entre servicios internos, en plataformas de ejecución o durante flujos de integración con terceros.
La autenticación no dice por sí sola qué puede hacer ese actor. Solo establece una identidad verificable sobre la cual luego podrán aplicarse políticas de autorización.
La autenticación federada permite delegar la verificación de identidad en un proveedor confiable. En lugar de que cada servicio gestione credenciales propias de usuario, la identidad puede provenir de un sistema central o de un tercero confiable, como un proveedor corporativo o una plataforma de identidad.
Esto trae ventajas importantes:
Pero también introduce un requisito: entender bien qué se está confiando, qué claims se consumen y qué controles siguen siendo responsabilidad de cada servicio.
Un proveedor de identidad o IdP es el componente que autentica actores y emite evidencia verificable sobre esa autenticación, por ejemplo tokens o assertions. En una arquitectura distribuida su papel es central, porque se convierte en la raíz de confianza para múltiples componentes.
Eso obliga a cuidarlo especialmente:
En microservicios, muchos accesos críticos no son ejecutados por usuarios humanos, sino por workloads. Una identidad de workload permite que un servicio demuestre quién es sin depender de credenciales estáticas distribuidas manualmente.
Este enfoque es preferible a compartir usuarios técnicos o secretos de larga vida porque mejora:
Una solicitud iniciada por un usuario puede atravesar varios servicios. En ese recorrido surge una decisión importante: cómo propagar la identidad original y cómo combinarla con la identidad del servicio que actúa en cada salto.
Existen varias estrategias, pero todas requieren cuidado:
La autorización responde otra pregunta: qué puede hacer esa identidad. En microservicios esto aplica tanto a usuarios como a servicios. Un servicio autenticado no debería poder consultar cualquier base, invocar cualquier API o publicar cualquier evento solo porque existe dentro del sistema.
La autorización entre servicios debería considerar:
No toda autorización necesita el mismo nivel de detalle. A veces alcanza con una política gruesa, como permitir que cierto servicio invoque una API específica. En otros casos hace falta una política fina, por ejemplo permitir leer ciertos recursos solo si pertenecen a un dominio o tenant concreto.
| Nivel | Ejemplo | Riesgo si se usa mal |
|---|---|---|
| Grueso | El servicio A puede llamar al servicio B | Permisos demasiado amplios si el recurso es sensible |
| Fino | El servicio A solo puede consultar órdenes del tenant X | Complejidad si se modela sin criterio |
| Contextual | Una acción solo se permite en cierto estado del proceso | Errores si el contexto no se propaga o valida bien |
Las decisiones de autorización suelen apoyarse en información asociada a la identidad: claims, scopes, roles, atributos o contexto del dominio. Esa información debe interpretarse con precisión. Leer mal un claim o asumir que un scope significa más de lo que realmente expresa puede abrir accesos no deseados.
Una buena práctica es mantener estos principios:
En algunos flujos un servicio actúa en nombre de un usuario o de otro servicio. Esa delegación debe modelarse explícitamente. Si se hace mal, se vuelve muy fácil que un componente termine usando privilegios que no le corresponden o que no quede claro quién tomó una acción.
La delegación segura requiere:
Una arquitectura sana separa la verificación de identidad de las reglas de negocio. El proveedor de identidad puede decir quién es el actor, pero la decisión de negocio sobre qué puede hacer dentro de un dominio específico corresponde al servicio o al componente de autorización adecuado.
Cuando esto se mezcla, los tokens terminan cargando demasiada semántica y los servicios pierden claridad sobre dónde se toman realmente las decisiones.
Una arquitectura distribuida solo puede considerarse madura cuando sabe responder con claridad quién está actuando, qué evidencia respalda esa identidad y qué permisos concretos tiene en cada contexto. La autenticación federada, la identidad de workload y la autorización bien modelada permiten construir esa confianza de forma escalable y auditable.
En el próximo tema profundizaremos en OAuth2, OpenID Connect, JWT y manejo seguro de tokens para ver cómo estos mecanismos materializan gran parte de la identidad y autenticación modernas.