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

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

Single Sign-On (SSO) es un esquema de autenticación donde un usuario se loguea una vez con un solo conjunto de credenciales y obtiene acceso a múltiples aplicaciones conectadas sin tener que loguearse de nuevo. Detrás de las cámaras, un identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, Auth0 — verifica al usuario, y un service provider (SP) — Slack, Salesforce, GitHub, tu app interna — acepta el token de verificación del IdP en lugar de pedir una contraseña.

SSO domina en el ámbito enterprise: un empleado típico toca 10-30 apps SaaS al día, y pedirles que se loguen en cada una por separado es un desastre de productividad + un desastre de seguridad por reutilización de contraseñas. Con SSO, el usuario se loguea en el IdP una vez al inicio del día laboral; cada app conectada acepta esa autenticación durante el resto de la sesión.

Cómo funciona SSO realmente

El flujo a alto nivel es el mismo entre protocolos, aunque los detalles de implementación difieren:

1. Usuario clica "Iniciar sesión" en el SP (la app que quiere usar).
2. SP redirige al usuario al IdP con una petición: "por favor autentica a este usuario por mí".
3. IdP autentica al usuario — verifica credenciales, puede también imponer MFA, políticas de acceso condicional ("solo en dispositivos gestionados"), límites de sesión.
4. IdP emite un token — una afirmación firmada criptográficamente que dice "este usuario está autenticado, y aquí está su identidad (email, nombre, pertenencias a grupos)".
5. IdP redirige al usuario de vuelta al SP con el token.
6. SP valida la firma del token usando la clave pública del IdP, luego confía en que el usuario es quien el IdP dice que es. SP crea una sesión local.

El usuario suele experimentar esto como un solo redirect del navegador — clica "Iniciar sesión con Okta", ve brevemente la página del IdP (o no, si ya está logueado), y aterriza de vuelta en la app ya autenticado. Tiempo total transcurrido: 1-2 segundos.

Los 3 protocolos SSO principales (SAML, OIDC, OAuth)

SAML 2.0

El abuelo del SSO enterprise, ratificado en 2005. SAML usa afirmaciones formateadas en XML intercambiadas entre IdP y SP, firmadas con certificados X.509. Es verbose, complejo de debuggear (XML codificado en base64 multilínea en parámetros de URL o cuerpos POST), pero sólido como una roca y omnipresente en enterprise. Si una app SaaS dice "SSO soportado", casi seguro se refiere a SAML 2.0. Slack, Salesforce, AWS, Workday — todos SAML.

OpenID Connect (OIDC)

El sucesor moderno, construido sobre OAuth 2.0 y JSON Web Tokens (JWTs). OIDC es lo que mueve "Iniciar sesión con Google", "Iniciar sesión con Apple", "Iniciar sesión con Microsoft". Basado en JSON, más simple de implementar, bien soportado en librerías de auth modernas. Productos SaaS más nuevos empiezan con OIDC y añaden SAML después para clientes enterprise que insisten.

OAuth 2.0 (técnicamente no es SSO)

OAuth es un framework de autorización — "¿puede esta app acceder a los datos de este usuario?" — no estrictamente un framework de autenticación. Pero se confunde habitualmente con SSO porque se usa el mismo flujo basado en redirect. "Iniciar sesión con GitHub" usa OAuth: la app obtiene un token para llamar a la API de GitHub como el usuario, e infiere la identidad de eso. OIDC añade claims de identidad estandarizados sobre OAuth, lo que lo convierte en SSO real.

Service Provider Initiated vs Identity Provider Initiated

Los logins SSO empiezan en uno de dos sitios:

• SP-initiated: Usuario va a https://app.example.com primero, pulsa Iniciar sesión, es redirigido al IdP, vuelve. Esta es la mayoría aplastante de los flujos del mundo real.
• IdP-initiated: Usuario empieza en el lanzador de apps del IdP (ej. dashboard de Okta), clica el tile del SP. El IdP genera una afirmación no solicitada y la POSTea al SP, que loguea al usuario directamente. Conveniente pero más complejo desde el punto de vista de seguridad — un SP debe aceptar afirmaciones que no pidió.

La mayoría de apps SaaS SAML soportan ambas. OIDC es esencialmente solo SP-initiated por diseño.

Por qué SSO mejora la seguridad (contraintuitivamente)

Parece que "un login para todo" debería hacer que el blast radius de una credencial robada sea mayor. En la práctica, lo opuesto es cierto:

• Imposición centralizada de MFA. Imponer MFA en 30 apps individuales es imposible — algunas apps no lo soportan, otras tienen implementaciones débiles. Con SSO, impones MFA fuerte en el IdP, y cada app conectada se beneficia.
• Un sitio para revocar acceso. Cuando un empleado se va, deshabilitas su cuenta IdP una vez y pierde inmediatamente acceso a cada app conectada. Sin SSO, estarías borrando cuentas en 30 sitios (y olvidando algunos).
• No más reutilización de contraseñas. Usuarios con contraseñas separadas para 30 apps las reutilizan. SSO elimina el problema de reutilización en la fuente — el usuario solo tiene una contraseña que gestionar.
• Rastro de auditoría en un sitio. Actividad de login, retos MFA, intentos fallidos — todo visible en los logs del IdP. Sin SSO, los datos de auditoría están fragmentados entre 30 proveedores.

Gotchas comunes de SSO

• Just-in-time (JIT) provisioning. Muchas apps SaaS SAML crean registros de usuario en el primer login SSO. Si tu IdP incluye pertenencias a grupos en la afirmación, el SP también puede asignar roles automáticamente. Sin JIT, un admin crea cada usuario manualmente antes de que pueda loguearse — bien para equipos pequeños, doloroso a escala.
• Mapeo de claims de grupo. El IdP suele enviar pertenencias a grupos en la afirmación. El SP debe mapear esos grupos a roles locales. Mapeos de grupo mal configurados son la fuente #1 de tickets "¿por qué no soy admin?" tras una migración SSO.
• Clock skew. Las afirmaciones SAML tienen timestamps de validez NotBefore y NotOnOrAfter. Si los relojes de IdP y SP difieren más del skew configurado (normalmente 60-300 segundos), la autenticación falla. Sincroniza todo por NTP.
• Rotación de certificados. SAML firma afirmaciones con certs X.509 que expiran (normalmente cada 1-3 años). Olvidar rotar certs antes de que expiren tira SSO a las 03:00 un martes. Recordatorios de calendario son obligatorios.
• Logout SP-initiated vs single logout. Cerrar sesión del SP no necesariamente cierra sesión del IdP u otros SPs conectados. Single Logout (SLO) es desordenado en la práctica y muchos proveedores no lo implementan completamente. En enterprise, los usuarios a menudo solo cierran el navegador.
• Desajustes de duración de sesión. Si el IdP da una sesión de 12 horas pero el SP impone sesiones de 1 hora, los usuarios son re-promptados constantemente aunque estén "ya logueados". Alinea las duraciones cuidadosamente.

SSO vs Federated Identity vs OAuth — ¿qué es qué?

Estos tres términos se enredan. Desambiguación rápida:

• SSO (Single Sign-On): Patrón de experiencia de usuario — un login, muchas apps. No dice nada sobre cómo se implementa.
• Federated identity: La capacidad técnica de que un IdP y SP confíen entre sí cruzando límites organizacionales. SSO suele requerir federated identity; federated identity puede también habilitar otras cosas (ej. compartir atributos de usuario).
• OAuth 2.0: Un protocolo de autorización (delegar acceso a datos). Usado como bloque de construcción para OIDC, pero por sí solo no establece identidad.
• OIDC: Una capa de autenticación encima de OAuth. Añade un ID token con claims de identidad estandarizados.

FAQ: Single Sign-On (SSO)

¿Cuál es la diferencia entre SSO y gestores de contraseñas?

Un gestor de contraseñas almacena credenciales separadas para cada app y las autocompleta — el usuario aún tiene 30 contraseñas distintas, solo escritas automáticamente. SSO reemplaza las 30 contraseñas con un login IdP: cada app confía en la verificación del IdP, no existe contraseña por app. SSO es más seguro (no es posible reutilizar contraseñas) pero requiere que cada app soporte un protocolo SSO.

¿Pueden los equipos pequeños usar SSO sin pagar precios enterprise?

Sí — Google Workspace y Microsoft 365 incluyen OIDC SSO para muchas apps SaaS sin coste extra. Auth0 tiene un nivel gratis para menos de 7.000 usuarios. Muchos IdPs open source (Keycloak, Authentik) son gratis para autohospedar. Las barreras de coste para SSO han bajado dramáticamente desde 2020.

¿Sigue siendo SAML relevante o debería usar solo OIDC?

Para integraciones nuevas, OIDC si ambos lados lo soportan — más simple, basado en JSON, más fácil de debuggear. Para SaaS enterprise, SAML sigue siendo requerido porque la mayoría de IdPs y catálogos SaaS enterprise lideran con SAML. Planea para ambos: implementa OIDC para signups self-service y SAML para contratos enterprise.

¿Qué es la SSO Tax?

La "SSO tax" es la práctica de proveedores SaaS de cobrar significativamente más por soporte SSO — a veces empujando clientes a niveles enterprise solo para obtener SSO. Hay un pushback de la industria (sso.tax trackea proveedores que hacen esto). Algunos proveedores han respondido incluyendo SSO en niveles más bajos; muchos no.

¿Qué es SCIM y cómo se relaciona con SSO?

SCIM (System for Cross-domain Identity Management) automatiza el provisioning y deprovisioning de usuarios entre IdP y SPs. SSO maneja la autenticación; SCIM maneja "crea este usuario cuando se añada al IdP, bórralo cuando se elimine". Juntos, SSO + SCIM es el estándar de oro para SaaS enterprise gestionado.

¿Qué pasa con SSO si el IdP cae?

Los usuarios no pueden loguearse en nada. Por eso la disponibilidad del IdP es crítica. La mayoría de IdPs publican SLAs del 99,99%; algunas empresas ejecutan un IdP de respaldo para failover. Para apps super-críticas, mantén al menos una cuenta admin local que omita SSO para acceso de emergencia.

Cómo LoadFocus integra con SSO

LoadFocus soporta SAML 2.0 y OIDC SSO en sus planes Enterprise. Conecta tu IdP (Okta, Microsoft Entra ID, Google Workspace, Auth0) una vez; provisiona miembros del equipo a través de las pertenencias a grupos de tu IdP; revoca acceso centralmente cuando alguien se va. Configura SSO desde tus ajustes de cuenta — instrucciones por IdP están en los docs.