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

De “quién eres” a “y ahora en todas partes”

Los artículos anteriores fueron sobre probar la identidad — factores, MFA, biometría. El Single Sign-On es sobre qué haces con esa prueba una vez que la tienes: reutilizar una sola autenticación en muchas aplicaciones para que el usuario no vuelva a ingresar credenciales en cada puerta.

El SSO es uno de los patrones de mayor apalancamiento en toda la identidad. Bien hecho mejora la experiencia de usuario y la seguridad al mismo tiempo — una combinación rara. Hecho con descuido concentra el riesgo tan estrechamente que una sola sesión robada desbloquea todo el parque de aplicaciones de una empresa. Este artículo trata de obtener el apalancamiento sin la mina.

Se apoya directamente en el módulo de protocolos: SAML, OAuth y OIDC son las lenguas que habla el SSO. Si están borrosas, mantenlas abiertas en otra pestaña — aquí asumimos que sabes qué es una aserción y un ID token, y nos enfocamos en la arquitectura y los trade-offs de coser muchas apps a un solo login.

Qué es el SSO en realidad

El Single Sign-On es un arreglo donde un usuario se autentica una vez contra un Proveedor de Identidad (IdP) central, y luego alcanza múltiples Proveedores de Servicio (SP / relying parties) independientes sin volver a autenticarse. Cada aplicación no verifica una contraseña por sí misma; confía en una aserción firmada del IdP que dice “esta es Sara, autenticada a esta hora, a este nivel de aseguramiento.”

El mecanismo descansa en dos sesiones que la gente suele confundir:

• La sesión del IdP — la sesión “maestra” creada cuando inicias sesión por primera vez. Vive en el proveedor de identidad (típicamente una cookie de navegador en el dominio del IdP).
• Las sesiones de los SP — una sesión separada que cada aplicación crea para ti después de aceptar la aserción del IdP. Son independientes y se gestionan localmente.

Esa distinción es la clave de todo lo que sigue. El SSO es fácil de razonar en el login — una sesión maestra acuña muchas sesiones de app — y difícil en el logout, precisamente porque esas sesiones de app son independientes.

sequenceDiagram
  accTitle: Flujo de Single Sign-On iniciado por el SP
  accDescr: Un usuario solicita una aplicación. La aplicación, al no encontrar sesión local, redirige el navegador al proveedor de identidad. El proveedor de identidad autentica al usuario con autenticación multifactor, establece 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 luego abre una segunda aplicación, esta redirige al proveedor de identidad, que ya tiene una sesión y devuelve una aserción de inmediato sin pedir credenciales de nuevo.
  actor U as Usuario (navegador)
  participant A as App / SP
  participant I as Proveedor de Identidad
  U->>A: Solicita página protegida
  A-->>U: Sin sesión — redirige al IdP
  U->>I: Solicitud de autenticación
  I->>U: Pide: credenciales + MFA
  U->>I: Entrega factores
  I->>I: Crea sesión del IdP
  I-->>U: Aserción firmada (redirige de vuelta)
  U->>A: Entrega la aserción
  A->>A: Valida firma, crea sesión del SP
  A-->>U: Acceso concedido
  Note over U,I: Después — segunda app
  U->>I: Solicitud de auth (la sesión del IdP ya existe)
  I-->>U: Aserción de inmediato — sin re-login

Los tres sabores del SSO

“SSO” nombra un objetivo, no una sola tecnología. Tres arquitecturas dominan, y confundirlas lleva a malas conversaciones de diseño.

Web SSO

El significado por defecto hoy: aplicaciones basadas en navegador federadas a un IdP sobre SAML u OIDC. Un login corporativo (Entra ID, Okta, Ping) desbloquea decenas de apps SaaS; un login de campus abre todos los sistemas universitarios. El IdP mantiene la sesión; cada SP cambia una redirección por una aserción. Aquí va la mayor parte del esfuerzo moderno y es lo que representa el diagrama de arriba.

Enterprise SSO

Inicio de sesión único extendido más allá del navegador a aplicaciones de escritorio y legacy dentro de una red — clientes pesados, sistemas on-prem, cosas que nunca hablaron SAML. Históricamente entregado por Kerberos con Active Directory (inicias sesión en Windows, obtienes un ticket, y las apps unidas al dominio lo aceptan en silencio) o por un agente de enterprise-SSO que inyecta credenciales almacenadas en apps que solo entienden usuario/contraseña. Es el primo más desordenado y viejo del Web SSO, muy vivo aún en grandes empresas con parques legacy.

Social SSO

“Inicia sesión con Google / Apple / Facebook.” Un proveedor de identidad de consumo actúa como IdP para sitios de terceros, sobre OIDC. Elimina la fricción del registro y descarga la gestión de contraseñas a un proveedor en el que el usuario ya confía. Los trade-offs son distintos al caso workforce: heredas las decisiones de seguridad de cuenta de ese proveedor, creas una dependencia de él, y debes pensar qué ocurre si un usuario pierde acceso a esa cuenta social. Ofrecer más de una opción, más un fallback nativo, es la mitigación habitual.

Iniciado por el IdP vs iniciado por el SP

El diagrama de arriba mostró un flujo iniciado por el SP: el usuario empieza en la aplicación, que lo rebota al IdP. Hay un segundo patrón que vale conocer porque se comporta — y falla — distinto.

• Iniciado por el SP: el usuario aterriza primero en la app (un marcador, un deep link), no encuentra sesión, y es redirigido al IdP para autenticarse, y de vuelta. Este es el flujo común y recomendado. Como la app inició el intercambio, puede validar que la aserción devuelta responde a su petición específica.
• Iniciado por el IdP: el usuario empieza en el IdP (un portal o “app launcher”), hace clic en un mosaico, y el IdP envía una aserción no solicitada directo a la app. Cómodo, pero más riesgoso: la app recibe una aserción que nunca pidió, así que no puede correlacionarla con una petición pendiente — lo que históricamente abrió la puerta a ataques de replay de aserción y estilo login-CSRF. OIDC en gran medida desalienta el patrón no solicitado por esta razón.

La guía práctica: prefiere iniciado por el SP, y si debes soportar iniciado por el IdP (muchos portales empresariales dependen de él), endurécelo con validación estricta de aserción, ventanas de tiempo ajustadas y protección contra replay. Saber en qué flujo estás explica muchos incidentes de “por qué este login de SSO se comportó raro”.

Cómo se establece la confianza

El SSO solo funciona porque cada SP tiene una relación de confianza preestablecida con el IdP. Esa confianza no es magia — es configuración concreta, y es donde vive un número sorprendente de fallas y vulnerabilidades.

• Intercambio de metadata. En SAML, IdP y SP intercambian metadata (entity IDs, URLs de endpoints y certificados de firma públicos). Esto le dice a cada lado a dónde enviar mensajes y cómo verificar firmas. OIDC hace el equivalente mediante un documento de discovery (.well-known/openid-configuration) y registro de cliente dinámico o manual.
• Claves de firma. El IdP firma las aserciones con su clave privada; el SP verifica con el certificado público del IdP. Si ese certificado expira (una causa clásica de outage) o se cambia sin coordinación, todos los logins se rompen a la vez. Si un SP es descuidado sobre qué clave confía, las aserciones falsificadas se vuelven posibles — la esencia del ataque Golden SAML, donde un adversario que roba la clave de firma del IdP puede acuñar aserciones válidas para cualquiera.
• Mapeo de atributos. La aserción carga claims (email, grupos, roles). El SP los mapea a sus propios usuarios y permisos. Equivoca el mapeo — confiar en un claim de email no verificado, sobre-confiar en un atributo de grupo — y tienes un bug de autorización montado sobre un login que funciona.
• Aprovisionamiento just-in-time. Muchos SP crean una cuenta local en el primer login de SSO a partir de los atributos de la aserción (JIT provisioning), para que los usuarios no tengan que pre-crearse. Esto se empareja con SCIM (del módulo de protocolos) para el ciclo de vida más completo: el SSO maneja la autenticación, SCIM maneja el aprovisionamiento y desaprovisionamiento de la cuenta misma. Confundir ambos es común — que el SSO inicie sesión de un usuario no, por sí solo, elimina su cuenta cuando se va; eso es trabajo de SCIM.

Los beneficios: por qué casi todos lo adoptan

El SSO es raro en que su caso de usabilidad y el de seguridad apuntan en la misma dirección.

• Experiencia de usuario. Un login en vez de decenas. Sin malabarear contraseñas por app, sin re-autenticarse todo el día. Este es el triunfo visible y el que consigue el presupuesto.
• Menos password fatigue → menos malos hábitos. Cuando la gente gestiona una credencial fuerte en vez de cuarenta, deja de reutilizar contraseñas, de escribirlas en post-its y de elegir variantes de Empresa2026!. Eliminas las contraseñas de las apps individuales por completo — una app federada a tu IdP no tiene contraseña que filtrar.
• Postura de seguridad más fuerte y centralizada. Aplicas MFA, acceso condicional, política de contraseñas y reglas basadas en riesgo una vez, en el IdP, y cada app conectada las hereda. Agrega un nuevo requisito resistente a phishing y protege todo el parque a la vez.
• Ciclo de vida más rápido y seguro. El onboarding concede acceso a través de una identidad; el offboarding es el grande — deshabilita la identidad central y quien se va pierde todas las apps conectadas de golpe, en lugar de esperar que cuarenta cuentas separadas se limpien (nunca se limpian todas).
• Auditabilidad. Los eventos de autenticación convergen en un sistema, así que tus logs, detección de anomalías e ITDR tienen un único stream de alto valor que vigilar.

Qué no es el SSO: conceptos vecinos

El SSO se confunde con tres vecinos, y mantenerlos distintos afila tus conversaciones de diseño.

• El SSO no es un gestor de contraseñas. Un gestor de contraseñas sigue dándole a cada app su propia contraseña; solo las guarda y autocompleta por ti. Cada app conserva una credencial separada que puede filtrarse individualmente, y no hay un punto central que deshabilitar en el offboarding. El SSO elimina la contraseña por-app por completo al hacer que las apps confíen en el IdP. Un gestor de contraseñas es un paliativo para un mundo sin SSO; el SSO es el arreglo estructural.
• El SSO no es “same sign-on”. Algunas configuraciones sincronizan el mismo usuario y contraseña a muchas apps (vía un directorio) para que se sienta unificado — pero cada app sigue autenticando de forma independiente contra su propia copia. El SSO verdadero tiene un evento de autenticación y una sesión en la que las otras confían; el same-sign-on tiene muchas autenticaciones que solo comparten una credencial.
• El SSO no es autorización. Iniciar sesión por el IdP prueba quién eres; no decide qué puedes hacer dentro de cada app. Eso es autorización — el tema de los módulos que siguen — y una app debe seguir aplicando sus propios permisos encima de un login de SSO exitoso. Tratar una aserción de SSO válida como si concediera acceso es un error clásico.

Cuando una app no puede hacer SSO

Los parques reales nunca están 100% federados, y los huecos son donde se acumula el riesgo. Algunas apps no soportan SAML u OIDC (software más viejo o barato), algunos proveedores ponen el SSO detrás de un tier premium (el llamado “impuesto de SSO”), y algunos sistemas legacy solo entienden un usuario y contraseña locales. Estas excepciones importan porque son justo las cuentas que escapan de los beneficios de arriba: conservan sus propias contraseñas, se pasan por alto en el offboarding, y no heredan tu MFA central.

Manejo práctico: presiona a los proveedores por soporte de estándares y presupuesta el tier de SSO en todo lo sensible; donde una integración de SSO real sea imposible, recurre a un gestor de contraseñas o vault de acceso privilegiado con MFA por-app y runbooks deliberados de offboarding; e inventaría las excepciones para saber con precisión qué cuentas quedan fuera del núcleo federado y gobernado centralmente. La meta no es la perfección — es saber dónde termina tu cobertura.

El riesgo central: romper la cadena

Cada beneficio del SSO viene de la concentración — y la concentración es también su peligro definitorio. Cuando muchas aplicaciones confían en un proveedor de identidad, ese proveedor se vuelve un único punto de compromiso. Rómpelo, y rompes todo aguas abajo. Los profesionales lo llaman romper la cadena; la gente de riesgo lo llama blast radius.

Los modos de falla se siguen directamente:

• Phishing al login del IdP. Un atacante ya no necesita hacer phishing a cuarenta apps — hace phishing al único login que desbloquea todas. El IdP es ahora el objetivo de credencial más valioso de la organización.
• Una sesión del IdP robada. Si un atacante roba la sesión maestra (session-hijacking, un token robado, malware en el dispositivo), hereda el SSO a cada app conectada sin re-autenticarse — la misma ausencia de fricción que ayuda al usuario ayuda al atacante.
• Disponibilidad. Si el IdP está caído, los usuarios no pueden entrar a nada federado a él. El SSO hace del IdP una dependencia crítica de negocio, no solo de seguridad.
• Confianza mal configurada. Un solo ajuste de federación malo — una validación de aserción laxa, un certificado de firma vencido, una confianza demasiado amplia — puede exponer muchos SP a la vez.

La técnica Golden SAML y varias brechas de alto perfil relacionadas con IdP son exactamente este riesgo hecho realidad: compromete la capa de identidad y el movimiento lateral hacia todo lo federado es casi gratis.

Mitigar el blast radius no significa abandonar el SSO — la alternativa (decenas de contraseñas independientes) es peor. Significa (1) endurecer el IdP de forma desproporcionada, (2) mantener las sesiones maestras cortas y re-verificar a nivel de app para acciones de alto valor vía step-up, y (3) no confiar ciegamente en la sesión de SSO para siempre — que es exactamente la mentalidad de verificación continua de Zero Trust.

¿Cuánto debe vivir la sesión maestra?

Una palanca de diseño que la gente subutiliza: la vida de la sesión maestra del IdP fija con qué frecuencia los usuarios enfrentan un login real y, crucialmente, acota cuánto tiempo una sesión maestra robada sigue siendo útil. Demasiado larga (semanas de “mantener sesión iniciada”) y la experiencia de SSO sin fricción se vuelve una experiencia sin fricción para el atacante; demasiado corta y re-autenticas a la gente constantemente y erosionas todo el beneficio del SSO.

La respuesta moderna no es un número fijo sino uno basado en riesgo, ligándose a las ideas adaptativas del artículo de factores: una sesión de bajo riesgo en un dispositivo gestionado y que cumple puede durar cómodamente, mientras que una sesión en un dispositivo no gestionado, desde una nueva ubicación, o buscando recursos sensibles obtiene una correa más corta y re-verificación más frecuente. Empareja una vida absoluta sensata con step-up en la app para acciones de alto valor, y obtienes la comodidad de una sesión de SSO de larga vida sin concederle poder ilimitado. Aquí es exactamente donde el SSO deja de ser “entra una vez para siempre” y empieza a ser “entra una vez, pero sigue probando que aún eres tú cuando importa” — el puente a Zero Trust.

Single Logout: la mitad difícil y descuidada

Si el login es el triunfo del SSO, el logout es su problema sin resolver. Iniciar sesión una vez es elegante. Cerrar sesión una vez — Single Logout (SLO) — significa propagar una señal de “sesión terminada” a cada aplicación que el usuario abrió, cada una con su propia sesión independiente, a menudo en dominios distintos. Eso es genuinamente difícil, y por eso tantos despliegues de “SSO” no implementan ningún SLO real en silencio.

Por qué es difícil

• Sesiones de SP independientes. Recuerda el modelo de dos sesiones: matar la sesión del IdP no mata automáticamente las sesiones de app que engendró. A cada SP hay que avisarle, y debe cumplir.
• El IdP a menudo no sabe quién sigue abierto. Debe rastrear cada SP con el que el usuario estableció sesión durante esta sesión maestra, y luego alcanzar a cada uno para invalidar — contabilidad fácil de equivocar.
• El logout de front-channel funciona redirigiendo el navegador por una cadena de URLs de logout por app (a menudo vía iframes ocultos). Es frágil: se rompe cuando una pestaña ya está cerrada, cuando las cookies de terceros están bloqueadas (cada vez más el default del navegador), o cuando alguna app de la cadena es lenta o inalcanzable.
• El logout de back-channel hace que el IdP llame al endpoint de logout de cada SP servidor a servidor (OIDC Back-Channel Logout, SAML SLO). Más robusto, pero solo funciona si cada SP implementa y honra ese callback — y muchos no lo hacen.
• Cualquier app perdida deja una sesión viva. El logout solo es tan completo como el participante más débil. Un SP que ignora la señal, y el usuario que cree haber cerrado sesión en todas partes sigue con una puerta abierta — en una computadora compartida o pública, eso es una exposición real.

Qué hace la buena práctica al respecto

• Sesiones de vida corta para que un logout perdido se auto-cure rápido — a menudo más efectivo en la práctica que intentar que el SLO sea perfecto.
• Logout de back-channel donde el protocolo y los SP lo soportan, tratado como mecanismo principal, con el front-channel como limpieza best-effort.
• Re-autenticación para acciones sensibles para que una sesión persistente no pueda, por sí sola, hacer daño.
• UX clara sobre qué hizo realmente el “cerrar sesión” — cerrar la app vs cerrar todo el parque de SSO son actos distintos, y los usuarios merecen saber cuál ocurrió.

Un día en la vida: Sara por todo el parque

Los flujos concretos hacen encajar el modelo de dos sesiones. Sara es enfermera en un hospital que federa sus apps a un IdP.

• 8:00 — primer login. Abre la app de horarios. No tiene sesión para ella, así que redirige al IdP. Se autentica con una passkey (resistente a phishing) más una laptop gestionada y que cumple. El IdP crea su sesión maestra y devuelve una aserción firmada; la app de horarios la valida y crea su propia sesión. Transcurrido: unos segundos.
• 8:05 — segunda app, sin login. Abre el sistema de registros. Redirige al IdP — pero la sesión maestra ya existe, así que el IdP devuelve una aserción de inmediato, sin pedir nada. Para Sara se siente como si la app “simplemente la conociera”. Ese segundo login silencioso es todo el punto del SSO — y la razón por la que una sesión maestra robada es tan peligrosa.
• 12:30 — una acción sensible. Intenta exportar un lote de registros de pacientes. La app no se apoya en el login de hace horas; dispara step-up, pidiéndole re-verificar con su passkey ahora mismo. La sesión era válida, pero la acción ameritaba prueba fresca.
• 17:00 — se va por el día en una estación compartida y hace clic en “cerrar sesión”. La sesión del IdP termina y, donde el logout de back-channel está conectado, se les dice a las apps conectadas que terminen sus sesiones también. Cualquier app que no honre el callback mantiene una sesión viva — que es justo por qué la estación también aplica un idle timeout corto como respaldo.
• Tres semanas después — cambia de empleador. TI deshabilita su única identidad central. Al instante no puede autenticarse a nada federado al IdP, y el desaprovisionamiento por SCIM elimina sus cuentas locales. Compara eso con un mundo sin SSO donde cuarenta cuentas separadas tendrían que encontrarse y cerrarse a mano.

Cada concepto de SSO — sesión maestra vs de app, re-login silencioso, step-up, propagación de logout, offboarding de un interruptor — aparece en un solo día ordinario.

Malas configuraciones comunes de SSO

La mayoría de incidentes de SSO no son rupturas exóticas de protocolo; son errores de configuración. Los recurrentes vale memorizarlos como checklist de revisión:

• Validación de aserción débil o ausente. No comprobar la firma, la audiencia (aud), el destinatario previsto, la ventana de tiempo (NotBefore/NotOnOrAfter), o el replay. Cada omisión convierte una aserción robada o falsificada en un login válido.
• Confianza de atributos demasiado amplia o falsificable. Confiar en un claim de email no verificado para emparejar cuentas deja a un atacante que controle un email coincidente secuestrar el mapeo. Confiar en un claim de grupo/rol sin limitar qué IdP puede afirmarlo es similar.
• Iniciado por el IdP dejado abierto de par en par. Aceptar aserciones no solicitadas sin protección contra replay ni tiempo ajustado, como se notó arriba.
• Sin MFA en el propio IdP. Federar cuarenta apps a un IdP protegido solo por una contraseña recrea el riesgo de blast radius en su peor forma — una contraseña con phishing desbloquea todo.
• Certificados de firma expirados o mal rotados. El outage clásico; también un riesgo de seguridad si un SP es indulgente al aceptar nuevas claves.
• Expectativas de logout desalineadas. Asumir que “cerrar sesión” es global cuando solo hay front-channel best-effort configurado, dejando sesiones vivas en máquinas compartidas.
• Secretos de cliente por defecto o compartidos en clientes OIDC, o comodines en el redirect-URI que dejan a un atacante capturar un authorization code.

Ninguno de estos es sutil una vez que sabes buscarlo — ese es el punto. Una revisión de SSO es en gran medida recorrer esta lista para cada federación que operas.

Recapitulación

El Single Sign-On es uno de los mejores trades de la identidad — cuando respetas lo que concentra.

1. El SSO reutiliza una autenticación en muchas apps vía un IdP central, apoyándose en una sesión maestra del IdP que acuña sesiones de SP independientes.
2. Viene en tres sabores — Web SSO (SaaS con SAML/OIDC), Enterprise SSO (Kerberos/AD, agentes, legacy) y Social SSO (inicia sesión con un IdP de consumo).
3. Sus beneficios alinean UX y seguridad: menos contraseñas, MFA/política centralizados, y — el que gana presupuestos — offboarding de un solo interruptor.
4. Su riesgo central es la concentración: romper la cadena en el IdP rompe todo aguas abajo, así que el IdP debe ser tu sistema más endurecido, tier-0.
5. El Single Logout es la mitad descuidada — genuinamente difícil porque las sesiones de SP son independientes — así que diseña con sesiones cortas, logout de back-channel, step-up y revocación server-side en vez de confiar en un logout perfecto.

Tres preguntas para autoevaluarte

1. Explica, usando el modelo de dos sesiones, por qué hacer clic en “cerrar sesión” en una app de SSO puede dejarte aún con sesión iniciada en otra. ¿Qué dos mecanismos reducen esa exposición?
2. Tu empresa federa 60 apps SaaS a un IdP. Un miembro del consejo pregunta “¿no estamos poniendo todos los huevos en una canasta?” Da la respuesta honesta: ¿qué concentra el SSO, y qué cuatro controles hacen aceptable esa concentración?
3. Compara Social SSO y Web SSO para una app fintech de consumo. ¿Cuál ofrecerías, qué dependencia crea cada uno, y qué fallback nativo conservas?

Ejercicios prácticos

1. Rastrea un flujo de SSO real. Inicia sesión en cualquier sitio con “Iniciar sesión con Google”, usando la pestaña de red de las dev-tools del navegador. Identifica la redirección al IdP, el token/aserción devuelto, y el momento en que la app crea su propia cookie de sesión. Bosqueja la secuencia.
2. Inspecciona las dos sesiones. Tras un login de Web SSO, usa las dev-tools para listar las cookies del dominio del IdP y del dominio de la app. Nota que son separadas — esa separación es por qué el SLO es difícil.
3. Audita una afirmación de SLO. Elige la documentación de un producto SaaS y determina si soporta SAML SLO u OIDC Back-Channel Logout, y si es front- o back-channel. Escribe una frase sobre qué le pasaría a la sesión de esa app si la señal de logout del IdP no llegara.