Single Sign-On (SSO): un login, muchas aplicaciones

La mañana de Sara, y su último día

Sara López es enfermera en un hospital que conecta todas sus aplicaciones a un único proveedor de identidad. A las 8:00 abre la app de turnos, que la manda al proveedor de identidad, donde inicia sesión con una passkey en su portátil gestionado. A las 8:05 abre el sistema de historias clínicas y la deja pasar directamente, sin pedirle nada. A ella le parece que la app ya la conocía. Tres semanas después, cuando se cambia a otro hospital, el equipo de TI desactiva una sola identidad y esa misma tarde ya no puede entrar en ninguna de las decenas de aplicaciones que usaba.

Eso es el inicio de sesión único (SSO), y las dos mitades de la historia importan. Los artículos anteriores trataban de demostrar la identidad: factores, MFA, biometría. El SSO trata de qué pasa con esa prueba una vez que la tienes, de reutilizar una sola autenticación en muchas aplicaciones para que el usuario no tenga que escribir credenciales en cada puerta. Es uno de los patrones más valiosos de la identidad porque mejora a la vez la usabilidad y la seguridad, algo poco habitual. Hecho sin cuidado, concentra el riesgo de tal manera que una sola sesión robada abre todas las aplicaciones de una empresa.

El SSO habla los protocolos del módulo anterior, SAML y OIDC sobre OAuth. Aquí damos por sabido qué es una aserción y qué es un ID token, y nos centramos en la arquitectura y los compromisos de atar muchas apps a un solo inicio de sesión.

Qué es de verdad el SSO

En el inicio de sesión único, un usuario se autentica una vez ante un proveedor de identidad (IdP) central y después llega a varios proveedores de servicio, o partes que confían, independientes, sin volver a autenticarse. Las aplicaciones no comprueban ninguna contraseña; confían en una aserción firmada del IdP que dice “esta es Sara, autenticada a esta hora, con este nivel de aseguramiento”.

El mecanismo descansa en dos tipos de sesión que se suelen confundir. La sesión del IdP es la sesión maestra que se crea en el primer inicio de sesión y vive en el proveedor de identidad, normalmente como una cookie en el dominio del IdP. Las sesiones de aplicación son sesiones aparte que cada app crea para ti después de aceptar la aserción del IdP, independientes entre sí y gestionadas en local. Esa distinción explica todo lo que viene. El SSO es fácil de entender al iniciar sesión, donde una sesión maestra genera muchas sesiones de aplicación, y difícil al cerrarla, justamente porque esas sesiones de aplicación son independientes.

sequenceDiagram
  accTitle: Flujo de inicio de sesión único iniciado por el proveedor de servicio
  accDescr: Un usuario pide una aplicación. La aplicación, sin sesión local, redirige el navegador al proveedor de identidad. El proveedor de identidad autentica al usuario con autenticación multifactor, crea su propia sesión y devuelve una aserción firmada a la aplicación. La aplicación valida la aserción y crea una sesión local. Cuando el usuario abre después una segunda aplicación, esta redirige al proveedor de identidad, que ya tiene sesión y devuelve una aserción al momento sin volver a pedir credenciales.
  actor U as Usuario (navegador)
  participant A as App / SP
  participant I as IdP
  U->>A: Pide una página protegida
  A-->>U: Sin sesión, redirige al IdP
  U->>I: Petición de autenticación
  I->>U: Pide credenciales + MFA
  U->>I: Aporta los factores
  I->>I: Crea la sesión del IdP
  I-->>U: Aserción firmada (redirección de vuelta)
  U->>A: Entrega la aserción
  A->>A: Valida la firma, crea la sesión de la app
  A-->>U: Acceso concedido
  Note over U,I: Más tarde, una segunda app
  U->>I: Petición (la sesión del IdP ya existe)
  I-->>U: Aserción al momento, sin nuevo inicio de sesión

Tres tipos de SSO

“SSO” nombra un objetivo, no una tecnología concreta. Dominan tres arquitecturas, y confundirlas lleva a conversaciones de diseño enredadas.

El SSO web es lo que casi todo el mundo entiende hoy: aplicaciones de navegador conectadas a un proveedor de identidad mediante SAML u OIDC. Un inicio de sesión corporativo con Entra ID, Okta o Ping abre decenas de apps SaaS; un inicio de sesión del campus abre todos los sistemas de la universidad. El IdP guarda la sesión y cada aplicación cambia una redirección por una aserción. Es donde va casi todo el esfuerzo moderno, y es lo que muestra el diagrama.

El SSO empresarial lleva el inicio de sesión único más allá del navegador, a aplicaciones de escritorio y heredadas dentro de una red, clientes pesados y sistemas locales que nunca hablaron SAML. Históricamente ha venido de Kerberos y Active Directory, donde inicias sesión en Windows, recibes un ticket y las apps unidas al dominio lo aceptan en silencio, o de un agente de SSO empresarial que rellena credenciales guardadas en apps que solo entienden usuario y contraseña. Es el primo mayor y más desordenado del SSO web, y sigue muy vivo en empresas grandes con sistemas heredados.

El SSO social es “Iniciar sesión con Google, Apple o Facebook”, donde un proveedor de identidad de consumo hace de IdP para webs de terceros sobre OIDC. Elimina la fricción del alta y deja la gestión de contraseñas en manos de un proveedor en el que el usuario ya confía. Los compromisos son distintos de los del caso de empleados: heredas las decisiones de seguridad de cuentas de ese proveedor, dependes de él y tienes que pensar qué pasa cuando un usuario pierde el acceso a esa cuenta social. Ofrecer más de una opción, más una alternativa propia, es la respuesta habitual.

Quién empieza el flujo

El diagrama mostraba un flujo iniciado por el proveedor de servicio: el usuario empieza en la aplicación, que lo manda al IdP. Hay un segundo patrón que conviene conocer, porque se comporta, y falla, de otra manera.

En el flujo iniciado por el SP, el usuario llega primero a la app, por un marcador o un enlace profundo, no tiene sesión, se le manda al IdP para autenticarse y vuelve. Es el flujo habitual y recomendado, y como la app empezó el intercambio, puede comprobar que la aserción que recibe responde a su propia petición. En el flujo iniciado por el IdP, el usuario empieza en el IdP, en un portal o lanzador de apps, pulsa un icono y el IdP envía directamente a la app una aserción no solicitada. Es cómodo pero más arriesgado: la app recibe una aserción que no pidió y no puede relacionarla con ninguna petición pendiente, lo que históricamente abrió la puerta a la reutilización de aserciones y al login CSRF. OIDC desaconseja en buena medida las aserciones no solicitadas por ese motivo. Prefiere el flujo iniciado por el SP y, si tienes que admitir el iniciado por el IdP, como hacen muchos portales empresariales, refuérzalo con una validación estricta de aserciones, ventanas de tiempo cortas y protección contra reutilización. Saber en qué flujo estás explica muchos incidentes raros de SSO.

Cómo se establece la confianza

El SSO solo funciona porque cada aplicación tiene una relación de confianza con el IdP establecida de antemano. Esa confianza es configuración concreta, y ahí viven una cantidad sorprendente de caídas y vulnerabilidades.

En SAML, el IdP y el proveedor de servicio intercambian metadatos: identificadores de entidad, URL de los endpoints y certificados públicos de firma, que le dicen a cada lado adónde enviar los mensajes y cómo comprobar las firmas. OIDC hace lo mismo con un documento de descubrimiento (.well-known/openid-configuration) y el registro del cliente. El IdP firma las aserciones con su clave privada y la aplicación las comprueba con el certificado público del IdP. Si ese certificado caduca, una causa clásica de caídas, o se cambia sin coordinarse, todos los inicios de sesión se rompen a la vez. Si una aplicación no tiene cuidado con la clave en la que confía, se pueden falsificar aserciones, que es la esencia del ataque Golden SAML: un atacante que roba la clave de firma del IdP puede fabricar aserciones válidas para cualquiera. Trata esa clave como una joya de la corona, guárdala en un HSM, restringe mucho el acceso y vigila emisiones inusuales.

La aserción lleva claims como el email, los grupos o los roles, y la aplicación los relaciona con sus propios usuarios y permisos. Si esa correspondencia está mal, porque te fías de un email sin verificar o te fías demasiado de un atributo de grupo, tienes un fallo de autorización montado sobre un inicio de sesión que funciona a la perfección. Muchas aplicaciones crean además una cuenta local en el primer inicio de sesión SSO a partir de los atributos de la aserción, que es el aprovisionamiento justo a tiempo. Se complementa con SCIM para el ciclo completo: el SSO se ocupa de la autenticación y SCIM de crear y retirar la propia cuenta. Se confunden a menudo, pero que el SSO deje entrar a un usuario no borra su cuenta cuando se va. Eso es trabajo de SCIM.

Por qué casi todo el mundo lo adopta

El SSO es raro en que sus argumentos de usabilidad y de seguridad apuntan en la misma dirección. La ventaja visible es un inicio de sesión en lugar de decenas, y es la que consigue el presupuesto. Detrás, quien gestiona una credencial fuerte en lugar de cuarenta deja de reutilizar contraseñas, de apuntarlas en pósits y de elegir variantes de Empresa2026!, y las aplicaciones dejan de guardar contraseñas, así que no hay nada en ellas que filtrar. La política de seguridad se centraliza: el MFA, el acceso condicional y las reglas basadas en riesgo se aplican una vez en el IdP y todas las apps conectadas lo heredan, de modo que un requisito nuevo resistente al phishing protege todo de golpe. Los eventos de autenticación confluyen en un solo sistema, lo que da a los logs, a la detección de anomalías y al ITDR un único flujo valioso que vigilar.

La ventaja en el ciclo de vida es la más fuerte de todas. El alta concede acceso a través de una identidad, y la baja, como mostró el último día de Sara, es un solo interruptor: desactivas la identidad central y quien se va pierde a la vez todas las apps conectadas, en lugar de confiar en que alguien limpie cuarenta cuentas por separado, cosa que nunca ocurre del todo. Si tienes que justificar el SSO ante alguien escéptico con el presupuesto, empieza por ahí y no por la comodidad. Es una historia de cumplimiento y de prevención de brechas que gusta a los auditores, y es justo donde fallan los entornos sin SSO, que acumulan cuentas huérfanas repartidas por decenas de herramientas SaaS.

Lo que el SSO no es

El SSO se confunde con tres vecinos. No es un gestor de contraseñas. Un gestor de contraseñas sigue dando a cada app su propia contraseña; solo las guarda y las rellena por ti, así que cada app conserva una credencial que puede filtrarse por su cuenta y no hay un punto central que desactivar en la baja. El SSO elimina la contraseña de cada app haciendo que confíen en el IdP. El gestor de contraseñas es una forma de apañarse sin SSO; el SSO es el arreglo estructural. Tampoco es el “mismo inicio de sesión” (same sign-on). Algunos entornos sincronizan el mismo usuario y la misma contraseña en muchas apps mediante un directorio para que parezca unificado, pero cada app sigue autenticando por su cuenta contra su propia copia. El SSO de verdad tiene una autenticación y una sesión en las que confían las demás. Y no es autorización. Iniciar sesión a través del IdP demuestra quién eres; no decide qué puedes hacer dentro de cada app. De eso tratan los módulos siguientes, y cada app tiene que seguir aplicando sus propios permisos encima de un inicio de sesión SSO correcto.

Cuando una app no puede hacer SSO

Ningún entorno real está federado del todo, y en los huecos se acumula el riesgo. Algunas apps no admiten SAML ni OIDC, algunos fabricantes ponen el SSO en un plan de pago superior, el llamado “impuesto del SSO”, y algunos sistemas heredados solo entienden un usuario y una contraseña locales. Esas excepciones son justo las cuentas que se escapan de las ventajas anteriores: mantienen sus propias contraseñas, se pasan por alto en las bajas y no heredan tu MFA central. Presiona a los fabricantes para que admitan los estándares y presupuesta el plan con SSO en todo lo sensible. Donde una integración real sea imposible, recurre a un gestor de contraseñas o a una bóveda de acceso privilegiado con MFA por app y un procedimiento de baja pensado a propósito. Y mantén un inventario de las excepciones, para saber exactamente qué cuentas quedan fuera del núcleo gobernado de forma central. El objetivo no es la perfección; es saber dónde termina tu cobertura.

El riesgo central: la concentración

Cada ventaja del SSO viene de la concentración, y la concentración es también su peligro definitorio. Cuando muchas aplicaciones confían en un único proveedor de identidad, ese proveedor se convierte en un punto único de compromiso, y se habla de su radio de impacto. Un atacante ya no necesita hacer phishing a cuarenta apps; se lo hace al único inicio de sesión que las abre todas, y eso convierte al IdP en el objetivo de credenciales más valioso de la organización. Una sesión del IdP robada, por secuestro de sesión, un token robado o malware en el dispositivo, le da al atacante SSO a todas las apps conectadas sin volver a autenticarse, la misma fluidez que ayuda a Sara a las 8:05 ayudando ahora al atacante. Si el IdP cae, nadie puede entrar en nada de lo conectado, lo que lo convierte en una dependencia crítica para el negocio y no solo para la seguridad. Y un único ajuste de federación malo, una validación laxa, un certificado de firma caducado, una confianza demasiado amplia, puede dejar expuestas muchas aplicaciones a la vez. Golden SAML y varias brechas sonadas relacionadas con proveedores de identidad son este riesgo hecho realidad: una vez cae la capa de identidad, moverse a todo lo federado sale casi gratis.

El SSO no elimina el riesgo; lo traslada y lo concentra en el proveedor de identidad. Es un buen trato solo si el IdP se defiende en consecuencia. Exige MFA resistente al phishing, FIDO2 o passkeys, para todo acceso y sobre todo para los administradores. Aplica acceso condicional según dispositivo, ubicación y riesgo. Mantén cortas las sesiones del IdP y exige reautenticación para las acciones sensibles. Valida las aserciones y las firmas con rigor. Y vigila de forma continua, alimentando el ITDR. Trata el IdP como infraestructura de nivel 0, como un controlador de dominio. Nada de esto significa renunciar al SSO, porque la alternativa, decenas de contraseñas independientes, es peor. Significa reforzar el IdP de forma desproporcionada, volver a comprobar en la aplicación las acciones valiosas mediante autenticación escalonada y no fiarse para siempre de la sesión SSO, que es la mentalidad de verificación continua de Zero Trust.

Cuánto debe durar la sesión maestra

Hay una palanca poco usada: la duración de la sesión maestra del IdP decide cada cuánto se enfrentan los usuarios a un inicio de sesión real y, sobre todo, cuánto tiempo sigue siendo útil una sesión maestra robada. Si dura semanas de “mantener la sesión iniciada”, la experiencia fluida del SSO también es fluida para los atacantes. Si es demasiado corta, la gente se reautentica sin parar y se pierde toda la ventaja.

La respuesta moderna es una duración según el riesgo y no un número fijo, enlazando con las ideas adaptativas del artículo de factores. Una sesión de bajo riesgo en un dispositivo gestionado y en regla puede durar cómodamente, mientras que una en un dispositivo no gestionado, desde una ubicación nueva o que busca recursos sensibles tiene la correa más corta y más comprobaciones. Combina una duración máxima sensata con autenticación escalonada en la aplicación para las acciones valiosas y tendrás la comodidad de una sesión SSO larga sin darle un poder ilimitado. A las 12:30, cuando Sara intenta exportar un lote de historias clínicas, el sistema no se fía de su inicio de sesión de hace cuatro horas; le pide que confirme con su passkey en ese momento. La sesión era válida, pero la acción merecía una prueba nueva.

Cierre de sesión único: la mitad difícil y olvidada

Si iniciar sesión es el triunfo del SSO, cerrarla es su problema sin resolver. El cierre de sesión único (SLO) consiste en enviar una señal de “sesión terminada” a cada aplicación que abrió el usuario, y cada una tiene su propia sesión independiente, a menudo en dominios distintos. Es difícil de verdad, y por eso muchas implantaciones de SSO no tienen, sin decirlo, ningún cierre de sesión único real.

Recuerda los dos tipos de sesión: terminar la sesión del IdP no termina automáticamente las sesiones de aplicación que generó. A cada aplicación hay que avisarla, y tiene que hacer caso. El IdP tiene que recordar todas las aplicaciones que abrió el usuario durante la sesión maestra y llegar a cada una, una contabilidad fácil de hacer mal. El cierre por el canal del navegador (front-channel) hace pasar al navegador por una cadena de URL de cierre de cada app, a menudo en iframes ocultos, y es frágil: se rompe cuando una pestaña ya está cerrada, cuando se bloquean las cookies de terceros, cosa que los navegadores hacen cada vez más por defecto, o cuando alguna app de la cadena va lenta o está caída. El cierre por canal trasero (back-channel) hace que el IdP llame al endpoint de cierre de cada aplicación de servidor a servidor, mediante OIDC Back-Channel Logout o SAML SLO. Es más robusto, pero solo funciona si todas las aplicaciones implementan y respetan la llamada, y muchas no lo hacen. El cierre es tan completo como su participante más débil. Basta una aplicación que ignore la señal para que quien cree haber cerrado sesión en todas partes siga teniendo una puerta abierta, y en un ordenador compartido o público eso es una exposición real.

La buena práctica se apoya en sesiones cortas, para que un cierre perdido se cure solo enseguida, lo que en la práctica suele dar más que intentar que el SLO sea perfecto. Usa el canal trasero como mecanismo principal allí donde el protocolo y las aplicaciones lo admiten, con el canal del navegador como limpieza de mejor esfuerzo. Exige reautenticación para las acciones sensibles, para que una sesión que se ha quedado colgada no pueda hacer daño por sí sola. Y es clara con los usuarios sobre lo que hizo de verdad “cerrar sesión”, porque cerrar sesión en una app y en todo el entorno son actos distintos. Cuando Sara cierra sesión a las 17:00 en un puesto compartido, la sesión del IdP termina y las aplicaciones conectadas al canal trasero terminan las suyas; las que no lo están mantienen una sesión viva, y por eso el puesto aplica además un tiempo de inactividad corto. Da por hecho que el cierre de sesión único es parcial y diseña alrededor de eso, con sesiones cortas, autenticación escalonada y revocación en el servidor, que trata el artículo de gestión de sesiones.

Errores de configuración habituales

La mayoría de los incidentes de SSO no son fallos exóticos de protocolo; son errores de configuración, y los que se repiten forman una buena lista de revisión. El primero es una validación de aserciones débil: no comprobar la firma, el destinatario, el receptor previsto, la ventana de tiempo o la reutilización, y cualquiera de esas omisiones convierte una aserción robada o falsificada en un inicio de sesión válido. Le sigue fiarse demasiado de los atributos. Emparejar cuentas por un claim de email sin verificar permite a un atacante que controle una dirección que coincida quedarse con la correspondencia, y fiarse de un claim de grupo o de rol sin limitar qué IdP puede afirmarlo es el mismo error. Después vienen el flujo iniciado por el IdP abierto de par en par, aceptando aserciones no solicitadas sin protección contra reutilización ni límites de tiempo, y un IdP sin MFA propio, que recrea el riesgo del radio de impacto en su peor forma, una contraseña robada por phishing que lo abre todo. Los certificados de firma caducados o mal rotados provocan la caída clásica y son un riesgo de seguridad si una aplicación es laxa al aceptar claves nuevas. Los equipos dan por hecho que “cerrar sesión” es global cuando solo hay configurado un cierre de mejor esfuerzo por el canal del navegador. Y los clientes OIDC se publican con secretos por defecto o compartidos, o con URI de redirección comodín que permiten a un atacante capturar un código de autorización. Ninguno de estos es sutil cuando sabes buscarlo, y de eso se trata: una revisión de SSO es en buena parte recorrer esta lista para cada federación que tengas.

Resumen

El inicio de sesión único es uno de los mejores tratos de la identidad, siempre que respetes lo que concentra. Reutiliza una autenticación en muchas apps a través de un IdP central, con una sesión maestra del IdP que genera sesiones de aplicación independientes. Hay tres tipos: SSO web con SAML y OIDC, SSO empresarial con Kerberos, Active Directory, agentes e integraciones heredadas, y SSO social con un proveedor de identidad de consumo. Sus ventajas alinean usabilidad y seguridad: menos contraseñas, MFA y políticas centrales y, la que gana presupuestos, la baja con un solo interruptor. Su riesgo central es la concentración, así que el IdP tiene que ser tu sistema más reforzado, de nivel 0. Y el cierre de sesión único es la mitad olvidada, difícil porque las sesiones de aplicación son independientes, así que diseña con sesiones cortas, cierre por canal trasero, autenticación escalonada y revocación en el servidor en lugar de fiarte de un cierre perfecto.

Tres preguntas para ponerte a prueba

1. Con los dos tipos de sesión, explica por qué pulsar “cerrar sesión” en una app con SSO puede dejarte con la sesión abierta en otra. ¿Qué dos mecanismos reducen esa exposición?
2. Tu empresa conecta 60 apps SaaS a un único IdP. Un miembro del consejo pregunta: “¿No estamos poniendo todos los huevos en la misma cesta?”. Da la respuesta honesta: ¿qué concentra el SSO y qué cuatro controles hacen aceptable esa concentración?
3. Compara el SSO social y el SSO web para una app fintech de consumo. ¿Cuál ofrecerías, qué dependencia crea cada uno y qué alternativa propia mantendrías?

Ejercicios prácticos

1. Sigue un flujo SSO real. Inicia sesión en cualquier web con “Iniciar sesión con Google” mientras miras la pestaña de red de las herramientas de desarrollo del navegador. Identifica la redirección al IdP, el token o la aserción que vuelve y el momento en que la app crea su propia cookie de sesión. Dibuja la secuencia.
2. Mira las dos sesiones. Tras un inicio de sesión SSO web, usa las herramientas de desarrollo para ver las cookies del dominio del IdP y las del dominio de la app. Fíjate en que están separadas; esa separación es la razón de que el cierre de sesión único sea difícil.
3. Audita una promesa de cierre único. Elige la documentación de un producto SaaS y averigua si admite SAML SLO u OIDC Back-Channel Logout, y si es por el canal del navegador o por canal trasero. Escribe una frase sobre qué pasaría con la sesión de esa app si la señal de cierre del IdP no le llegara.