¿Qué es el Single Sign-On (SSO)?

El single sign-on es un método de autenticación en el que un solo login en el proveedor de identidad da acceso a muchas aplicaciones independientes. El elenco tiene dos roles: el proveedor de identidad (IdP) autentica a los usuarios y responde por ellos; cada service provider (SP) — las apps que de verdad quieres usar — confía en ese aval en lugar de correr su propio login. Una distinción pedante que vale la pena guardar: apps que comparten un directorio pero piden la contraseña una por una son same sign-on — el mismo login, varias veces; el SSO de verdad significa que te pregunten una sola vez.

Puntos clave

La danza de redirects, paso a paso

¿Por qué redirects, para empezar? La política de mismo origen del navegador: app.example.com no puede leer una cookie de login de idp.example.org, así que la identidad debe viajar como un mensaje firmado a través del navegador y no como una cookie compartida — que es exactamente lo que hace el flujo:

1  El usuario abre app.example.com — sin sesión
2  El SP redirige al IdP con una solicitud de autenticación
3  El usuario se autentica EN EL IDP (contraseña + MFA) — o ya tiene
   una sesión en el IdP, y este paso se salta en silencio
4  El IdP emite una aserción firmada (XML de SAML) o un ID token (JWT de OIDC)
5  El navegador la entrega en la URL de callback del SP
6  El SP valida: firma · issuer · audience · expiración · replay
7  El SP inicia su propia sesión local — el usuario está dentro
8  Siguiente app: pasos 1–2, y luego directo del camino silencioso del 3 al 7

Así se ve el lado del service provider cuando un backend lo envuelve:

// JavaScript / Node.js — Back4app JS SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
const user = await Parse.User.logInWith('keycloak', {
  authData: {
    id: subClaim,              // the IdP's stable subject ID
    access_token: accessToken, // verified server-side against the IdP
  },
});
// One IdP login now serves every app that trusts the same issuer.

// Flutter / Dart — Back4app Flutter SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
final user = ParseUser.forQuery();
final response = await user.loginWith('keycloak', {
  'id': subClaim,              // the IdP's stable subject ID
  'access_token': accessToken, // verified server-side against the IdP
});
// One IdP login now serves every app that trusts the same issuer.

// iOS / Swift — Back4app Swift SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
let user = try await User.loginWith(
    "keycloak",
    authData: [
        "id": subClaim,              // the IdP's stable subject ID
        "access_token": accessToken  // verified server-side against the IdP
    ]
)
// One IdP login now serves every app that trusts the same issuer.

// Android / Kotlin — Back4app Android SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
val authData = mapOf(
    "id" to subClaim,              // the IdP's stable subject ID
    "access_token" to accessToken  // verified server-side against the IdP
)
ParseUser.logInWithInBackground("keycloak", authData).continueWith { task ->
    val user = task.result
    // One IdP login now serves every app that trusts the same issuer.
}

Iniciado por el SP vs. iniciado por el IdP

La mayoría de los explicadores describe solo el primero y nunca nombra el segundo — pero a los IdPs empresariales les encantan los mosaicos de panel, así que los SPs se encuentran con ambos. El panorama técnico de SAML especifica los dos perfiles; la regla práctica está en la última fila de la tabla.

SAML vs. OIDC

Y el triángulo que desenreda las siglas, de una vez: SAML y OIDC hacen autenticación para el SSO; OAuth 2.0 solo es autorización — OIDC es la capa de identidad que volvió la plomería de OAuth segura para iniciar sesión. El login social es la misma maquinaria OIDC con una plataforma de consumo como IdP y una sola app como audiencia; el SSO empresarial cambia de casero y ensancha la sesión a una suite.

Las partes que nadie menciona

El single logout (SLO) es la mitad difícil. El login converge hacia adentro, a un IdP; el logout debe abrirse hacia afuera, a cada SP con sesión local — y la cadena se rompe si una app no responde, las restricciones de cookies de terceros de los navegadores rompen las notificaciones de front-channel, y nada llega a tus otros dispositivos. En la práctica, “cerré sesión en todas partes” significa sesiones locales cortas que re-verifican la sesión (terminada) del IdP, no un broadcast confiable. Las sesiones corren en tres relojes: la sesión global del IdP, la sesión local de cada app y la ventana de validez de la propia aserción. Cerrar sesión en una app mientras la sesión del IdP vive significa reingreso silencioso en la siguiente visita — comportamiento que los usuarios reportan como bug y que los arquitectos deberían reconocer como el diseño. Y el impuesto del SSO: los proveedores de SaaS rutinariamente encierran el soporte de SAML/SSO detrás de planes enterprise a múltiplos del precio base — un hecho de mercado que merece presupuesto, ya que el requisito del equipo de seguridad y la línea de compras llegan juntos.

El radio de impacto, con honestidad

El SSO concentra el riesgo a propósito — eso es lo que “single” significa. Una cuenta comprometida en el IdP abre todas las apps conectadas; un IdP comprometido en sí — incluido el robo de sus claves de firma de aserciones, el patrón de ataque de la “aserción dorada” — acuña identidad válida para cualquiera, en cualquier parte. Los proveedores lo suavizan; la respuesta de ingeniería es gastar bien la concentración: MFA resistente al phishing en el IdP (ese único login ahora vale protección de nivel passkey), autenticación step-up para las apps sensibles en lugar de una sesión-manta, sesiones globales cortas donde el riesgo es alto, rotación y monitoreo de las claves de firma, y cuentas locales de emergencia para el día en que el IdP se caiga. El punto único de falla nunca desaparece — se blinda, porque blindar un solo punto es exactamente la economía que el SSO prometió.

Integrarse como service provider

Lo que “soportamos SSO” exige de verdad de un equipo de aplicación, en una lista: registra tu URL de callback/ACS en el IdP e intercambia metadatos (issuer, certificados); valida todo en cada aserción — firma, issuer, audience, expiración y vínculo anti-replay; mapea los claims del IdP a tu modelo de usuario, anclado en el subject estable, nunca en el email solo; provisiona just-in-time (el primer login por SSO crea el usuario local); maneja las llegadas iniciadas por el IdP de forma deliberada; y prueba las expectativas de logout contra la realidad de los tres relojes de arriba. Es un camino bien recorrido — por eso existen IdPs open-source como Keycloak para el otro lado del apretón de manos — pero cada punto que se salte es un hallazgo de seguridad con fecha marcada.

Casos de uso comunes

• Suites de apps corporativas — el caso canónico: un login por la mañana, todas las herramientas internas y SaaS después.
• SaaS B2B subiendo de mercado — “soporta SSO” como el checkbox que destraba el contrato enterprise.
• Educación y salud — acceso federado entre instituciones, donde las raíces de SAML son más profundas.
• MFA y offboarding centralizados — un solo lugar para imponer factores; un interruptor que termina en todas partes el acceso del empleado que se fue.
• Productos multi-app — tu propia suite compartiendo un login vía tu propio IdP, al estilo consumidor.

¿Deberías agregar SSO? Matriz de decisión

Limitaciones y trade-offs

• La disponibilidad se concentra junto con la identidad. La caída del IdP es la caída del login de todos; la redundancia y los caminos de emergencia son parte de la funcionalidad, no adiciones a ella.
• El logout es más débil que el login. El fan-out del SLO falla parcialmente por diseño; sesiones locales cortas, no broadcasts de logout, entregan la garantía real.
• La cola larga sigue con contraseña. Las apps sin soporte de SSO conservan sus propias credenciales — los gestores de contraseñas siguen siendo la capa de limpieza.
• Las capas de sesión confunden a los usuarios. El relogin silencioso y los tickets de “cerré sesión pero no” son la factura de UX del diseño de tres relojes; la documentación y los timeouts predecibles la amortizan.
• La calidad de integración varía por SP. El techo de seguridad del SSO lo fija la validación de aserciones más descuidada entre tus apps conectadas — la lista de arriba es por app, para siempre.

SSO en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Una app aquí se suma a un parque de SSO como service provider mediante el mismo mecanismo de adaptadores que impulsa el login social: Back4app trae adaptadores de autenticación para Keycloak, LDAP y emisores OAuth2/OIDC genéricos, así que el flujo de las pestañas de código — el IdP autentica, la app recibe tokens, logInWith los verifica del lado del servidor contra el emisor — convierte el SSO empresarial en configuración más un handler de redirect. Las identidades se anclan en el subject estable del IdP en bloques authData por proveedor, el primer login provisiona al usuario just-in-time, linkWith acopla métodos adicionales para el camino de emergencia, y la sesión que tu app emite sigue siendo una sesión Parse revocable — de modo que la pila de tres relojes termina, de tu lado, con un reloj que controlas por completo.