Tema 13
En ecosistemas modernos, una misma identidad necesita operar en múltiples aplicaciones sin repetir autenticación de forma aislada en cada una. Single Sign-On y federación de identidad buscan resolver ese problema compartiendo confianza entre sistemas. Bien diseñados, reducen fricción y mejoran control central. Mal implementados, amplifican el impacto de un error o compromiso.
Cuando cada aplicación maneja su propio login, los usuarios terminan con múltiples credenciales, la organización pierde control central y el ciclo de vida de acceso se vuelve más difícil de gobernar. Frente a eso, muchas arquitecturas adoptan autenticación centralizada y confianza entre aplicaciones.
Single Sign-On, o SSO, permite que una autenticación inicial habilite el acceso a múltiples sistemas relacionados. La federación de identidad amplía esa idea cuando los sistemas no pertenecen necesariamente al mismo dominio administrativo o cuando la autenticación se delega a otra organización o proveedor.
Para entender bien estos conceptos hay que mirar menos el “botón de login” y más las relaciones de confianza que existen detrás.
Single Sign-On es un enfoque en el que un usuario se autentica una vez ante un componente central y luego puede acceder a varias aplicaciones sin repetir login completo en cada una de ellas, siempre dentro del alcance de confianza definido.
La promesa principal del SSO es doble:
Sin embargo, SSO no significa que todas las aplicaciones compartan exactamente la misma autorización. Comparten autenticación o identidad validada, pero cada aplicación puede y debe seguir aplicando sus propias reglas de acceso.
La federación de identidad ocurre cuando un sistema acepta identidad emitida o validada por otro dominio de confianza. En lugar de autenticar localmente al usuario con su propia base de credenciales, una aplicación o servicio confía en una afirmación emitida por un proveedor externo o por otra organización.
Esto es especialmente útil cuando:
La clave de la federación no es compartir usuarios, sino compartir confianza verificable sobre la autenticación e identidad.
Ambos conceptos están relacionados, pero no son exactamente lo mismo. SSO describe la experiencia o el resultado de autenticarse una vez y reutilizar ese estado en varias aplicaciones. La federación describe el mecanismo de confianza entre dominios o sistemas distintos.
| Concepto | Pregunta principal | Foco |
|---|---|---|
| SSO | ¿Cómo evito que el usuario se autentique repetidamente? | Experiencia y reutilización del login |
| Federación | ¿Cómo confío en la identidad validada por otro dominio? | Relación de confianza entre sistemas o entidades |
En la práctica, muchas soluciones de SSO se implementan mediante federación, pero conviene separar mentalmente ambos planos.
En una arquitectura típica aparecen al menos estos actores:
La aplicación deja de validar directamente usuario y contraseña y pasa a confiar en la identidad emitida por el IdP dentro del marco acordado.
La federación depende de una relación de confianza explícita. Una aplicación no debería aceptar identidad de cualquier emisor, sino solo de aquellos configurados y validados como confiables.
Esa confianza suele involucrar:
Sin estas validaciones, la federación se convierte en una puerta para aceptar identidades no verificadas o mal emitidas.
Desde la perspectiva del usuario, SSO reduce fricción. Disminuye la cantidad de veces que debe autenticarse y reduce la necesidad de recordar múltiples credenciales para aplicaciones corporativas o integradas.
Esto tiene efectos positivos reales:
Sin embargo, la comodidad del usuario no es el único objetivo. De hecho, muchas veces la verdadera ganancia está del lado del gobierno central.
Para la organización, el valor de SSO y federación suele ser aún mayor que para el usuario:
Esto convierte al IdP en una pieza crítica de la arquitectura de identidad, no solo en una mejora de experiencia.
Uno de los errores más comunes es pensar que, si una aplicación ya recibe la identidad desde un proveedor central, entonces ya no necesita resolver autorización propia. Eso es falso.
El IdP puede decir quién es el usuario o proveer ciertos atributos. Pero la aplicación todavía debe decidir:
La autenticación puede delegarse. La autorización de negocio rara vez desaparece.
Cuando una aplicación acepta identidad federada, necesita traducir esa identidad a su modelo interno. Esto puede implicar mapear:
Si este mapeo es ambiguo o inconsistente, la aplicación puede asignar permisos incorrectos o aceptar identidades válidas pero mal asociadas.
SSO trae una ventaja evidente, pero también concentra riesgo. Si el punto central de autenticación falla o es comprometido, el impacto puede alcanzar a muchas aplicaciones al mismo tiempo.
Esto obliga a tratar al proveedor de identidad como un activo crítico. No es una pieza auxiliar. Debe diseñarse con:
No es lo mismo un ecosistema donde varias aplicaciones internas comparten el mismo IdP corporativo que una relación de federación con un proveedor SaaS externo o con otra organización.
En el primer caso, la organización suele tener más control sobre identidad, atributos y políticas. En el segundo, debe evaluar con cuidado:
Cuando una aplicación consume identidad federada, puede optar por distintas estrategias de representación local. A veces mantiene cuentas locales previamente creadas. Otras veces usa aprovisionamiento just-in-time al primer ingreso, creando una representación mínima del usuario a partir de la identidad emitida.
Este enfoque reduce fricción, pero debe diseñarse con cuidado. Si la creación local se hace de forma demasiado permisiva, puede aparecer sprawl de cuentas o asignación automática de permisos sin suficiente validación contextual.
El login centralizado suele ser más fácil de imaginar que el logout consistente. Cuando varias aplicaciones confían en una sesión central, surge una pregunta práctica: ¿qué significa cerrar sesión?
Puede haber varios niveles:
Una implementación incompleta puede hacer que el usuario crea haber salido, mientras algunas aplicaciones siguen aceptando una sesión vigente. Por eso el diseño de logout federado es un aspecto real de seguridad y experiencia.
Hasta aquí vimos el problema y la arquitectura conceptual. En el tema siguiente entraremos en los protocolos que materializan estos flujos de interoperabilidad: OAuth 2.0, OpenID Connect y SAML.
Lo importante es llegar a ese punto con claridad conceptual: los protocolos no existen para “hacer login moderno” por moda, sino para soportar confianza, delegación y federación entre sistemas de forma verificable.
Single Sign-On y federación de identidad permiten que múltiples aplicaciones confíen en una autenticación central o externa, reduciendo fricción y mejorando gobierno. Pero ese beneficio depende de relaciones de confianza bien definidas, validaciones estrictas y una separación clara entre autenticación compartida y autorización local.
En el próximo tema estudiaremos los protocolos más usados para implementar estas arquitecturas: OAuth 2.0, OpenID Connect y SAML.