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

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

El inicio de sesión único (Single Sign-On, SSO) permite iniciar sesión una vez y usar varias aplicaciones conectadas sin volver a autenticarse. Un proveedor de identidad (IdP), como Okta, Microsoft Entra ID, Google Workspace o Auth0, verifica al usuario. Cada aplicación, el proveedor de servicio (SP), confía en la confirmación firmada del IdP en lugar de pedir su propia contraseña. Es habitual en las empresas porque sustituye muchas contraseñas sueltas por un único acceso gestionado.

Cómo funciona el SSO

El flujo es parecido en todos los protocolos:

1. El usuario pulsa "Iniciar sesión" en la aplicación.
2. La aplicación redirige el navegador al IdP con una solicitud de autenticación.
3. El IdP autentica al usuario: contraseña, MFA, políticas de dispositivo o ubicación.
4. El IdP emite un token firmado (aserción o ID token) que indica quién es el usuario, a menudo con correo, nombre y grupos.
5. El navegador vuelve a la aplicación con el token.
6. La aplicación comprueba la firma con la clave pública del IdP y abre su propia sesión.

Para el usuario son un par de redirecciones. Si ya tiene sesión en el IdP, puede que ni vea una pantalla de acceso.

Los principales protocolos de SSO: SAML, OIDC y OAuth

SAML 2.0

Un estándar basado en XML que OASIS anunció en marzo de 2005. Las aserciones se firman con certificados X.509. Es verboso y más difícil de depurar que las alternativas modernas, pero está muy extendido en el software empresarial. Más detalles en qué es SAML.

OpenID Connect (OIDC)

Una capa de identidad ligera sobre OAuth 2.0. La aplicación recibe un ID token, un JSON Web Token firmado con datos de identidad. Está basado en JSON y es más fácil de implementar, por eso muchos productos nuevos empiezan con él.

OAuth 2.0

OAuth es un marco de autorización: responde a "¿puede esta app acceder a estos datos?", no a "¿quién es este usuario?". Se confunde con el SSO porque las redirecciones se parecen. OIDC añade la capa de identidad estándar que convierte el flujo en autenticación real. Los tokens de acceso que emite OAuth suelen enviarse como bearer token.

Inicio iniciado por el SP o por el IdP

• Iniciado por el SP: el usuario abre primero la aplicación, es redirigido al IdP y vuelve. Es el flujo más común.
• Iniciado por el IdP: el usuario parte del panel de aplicaciones del IdP y pulsa el icono de la aplicación; el IdP envía una aserción que la aplicación no había pedido. Es cómodo, pero exige más cuidado porque la aplicación debe aceptar una aserción no solicitada.

Por qué el SSO puede mejorar la seguridad

• MFA centralizada. La autenticación fuerte se exige una vez en el IdP y no en cada app.
• Un único sitio para revocar accesos. Al desactivar la cuenta de IdP de quien se va, pierde el acceso a todas las apps conectadas.
• Menos reutilización de contraseñas. Un acceso gestionado sustituye a muchas contraseñas.
• Un único registro de auditoría. Los inicios de sesión y los intentos fallidos aparecen en los registros del IdP.

La contrapartida es la concentración: el IdP pasa a ser una dependencia crítica y un objetivo atractivo, así que conviene protegerlo con MFA y mantener un acceso de emergencia fuera del SSO. Además, el SSO no decide qué puede hacer cada usuario; eso es autorización, mediante roles en la aplicación (véanse el control de acceso basado en roles y la gestión de identidades y accesos).

Errores comunes con el SSO

• Desfase de reloj. Las aserciones SAML llevan las marcas NotBefore y NotOnOrAfter; si los relojes del IdP y del SP se desvían más de lo permitido, el acceso falla. Sincroniza ambos con NTP.
• Certificados de firma caducados. Los certificados SAML caducan. Controla la fecha y renuévalos antes.
• Mapeo de grupos incorrecto. Si los grupos del IdP no se asignan a roles de la aplicación, tras una migración los usuarios tienen permisos equivocados.
• Sin plan de aprovisionamiento. Sin aprovisionamiento just-in-time ni SCIM, un administrador crea cada usuario a mano y quienes se van conservan cuentas obsoletas.
• Dar por hecho el cierre de sesión único. Cerrar sesión en una app a menudo no termina la sesión del IdP ni la de otras apps.
• Duraciones de sesión desiguales. Una sesión larga en el IdP junto a una corta en la app provoca peticiones constantes de acceso.

SSO, identidad federada y OAuth

• SSO es la experiencia de usuario: un acceso, muchas apps. No dice cómo se construye.
• Identidad federada es el acuerdo de confianza que permite a un IdP y a un SP de organizaciones distintas aceptar las identidades del otro.
• OAuth 2.0 delega el acceso a datos; por sí solo no establece quién es el usuario.
• OIDC añade a OAuth un ID token con datos de identidad.

Preguntas frecuentes sobre Single Sign-On (SSO)

¿En qué se diferencia el SSO de un gestor de contraseñas?

Un gestor de contraseñas guarda una credencial distinta para cada app y la rellena. El SSO elimina la contraseña por app: la aplicación confía en la verificación del IdP. El SSO exige que cada app lo admita; un gestor funciona con cualquier formulario de acceso.

¿SAML u OIDC?

Para una integración nueva, OIDC suele ser más sencillo de construir y depurar. Muchos clientes empresariales y proveedores de identidad siguen pidiendo SAML, así que los productos para organizaciones grandes suelen admitir ambos.

¿Qué es el "impuesto SSO"?

Es la práctica de cobrar bastante más por un plan que incluye SSO. El sitio sso.tax recoge qué proveedores lo hacen.

¿Qué es SCIM y qué relación tiene con el SSO?

SCIM (System for Cross-domain Identity Management) automatiza la creación, actualización y eliminación de cuentas entre el IdP y las aplicaciones. El SSO gestiona el acceso; SCIM, el ciclo de vida de las cuentas.

¿Qué pasa si el proveedor de identidad cae?

Los usuarios no pueden iniciar sesión en las apps que dependen de él, salvo que ya tengan una sesión válida. Para las apps críticas, mantén al menos una cuenta de administrador local de emergencia que no use SSO.

Pruebas de carga de una app con SSO

LoadFocus no ofrece inicio de sesión único con SAML ni OIDC: se entra con correo y contraseña o con Google, y se invita a los compañeros con acceso completo o de solo lectura. El SSO importa en la app que pruebas. Un inicio de sesión SSO real pasa por páginas del proveedor de identidad que una prueba de carga no debería saturar. Lo habitual es obtener un token una vez desde un cliente de prueba, por ejemplo con el flujo de credenciales de cliente de OAuth en un tenant de pruebas, y enviarlo en la cabecera Authorization. Consulta pruebas de carga con OAuth 2.0 y probar apps protegidas con OAuth en JMeter; las pruebas se ejecutan con las pruebas de carga de LoadFocus, también con scripts de JMeter.