¿Cómo funciona el inicio de sesión único y en qué se diferencian SAML y OIDC?
Respuesta breve
El SSO centraliza la autenticación en un proveedor de identidad (IdP). Cuando un usuario visita un proveedor de servicio (la app), la app redirige al IdP; el usuario inicia sesión una vez, y el IdP devuelve una aserción o token firmado que avala su identidad. SAML lo lleva como una aserción XML firmada; OIDC lo lleva como un token de identidad JSON firmado montado sobre OAuth 2.0. La app confía en la firma del IdP en lugar de manejar las contraseñas ella misma.
Las preguntas sobre SSO comprueban si entiendes la confianza federada: muchas aplicaciones externalizando el acto de autenticación a un único proveedor de identidad. Acertar con la distinción SAML-vs-OIDC demuestra que realmente has trabajado con ello.
El modelo central
En el SSO hay dos roles: el proveedor de identidad (IdP) que autentica a los usuarios y el proveedor de servicio (SP) —la aplicación— que se apoya en él. Cuando un usuario llega a la app, esta lo redirige al IdP. Si ya tiene sesión iniciada allí, no aparece ningún aviso; de lo contrario se autentica una vez. El IdP entonces devuelve el navegador a la app llevando una declaración criptográficamente firmada que dice «este es quien es el usuario». La app verifica la firma del IdP y crea una sesión local. El usuario introduce sus credenciales una sola vez y alcanza todas las apps federadas.
La gran ventaja es la centralización: un único lugar para imponer MFA, política de contraseñas, acceso condicional y desaprovisionamiento. Desactiva la cuenta en el IdP y el acceso en todas partes muere de golpe.
SAML vs OIDC
- SAML 2.0 es el estándar empresarial más antiguo. El IdP emite una aserción XML firmada, normalmente entregada vía un POST del navegador. Es maduro y omnipresente en B2B/empresa, pero el XML es pesado e incómodo para móvil y SPA.
- OIDC (OpenID Connect) es una capa de identidad montada sobre OAuth 2.0. El IdP emite un token de identidad JSON (un JWT) junto a los tokens OAuth. Es ligero, compatible con JSON/REST, y la opción por defecto para apps web, móviles y orientadas a API modernas.
Ambos se apoyan en que el SP verifique la firma del IdP para confiar en la aserción: esa firma es toda la base de la confianza.
El riesgo
El SSO concentra el riesgo: el IdP se convierte en un único punto de fallo y un objetivo apetecible. Si se compromete (o si una aserción SAML puede falsificarse por un fallo de análisis), el atacante obtiene todo. Por eso los IdP exigen la MFA más fuerte y resistente al phishing.
Qué buscan los entrevistadores
El modelo IdP/SP de redirección-y-aserción-firmada, la ventaja un-inicio-de-sesión-muchas-apps, SAML (XML firmado) vs OIDC (JWT sobre OAuth), la verificación de firma como raíz de la confianza, y la conciencia del radio de impacto concentrado.
Posibles preguntas de seguimiento
- ¿Por qué se prefiere OIDC sobre SAML para aplicaciones modernas y móviles?
- ¿Cuál es el radio de impacto si el IdP se compromete, y cómo se reduce?
- ¿Cómo verifica la app que una aserción SAML o un token de identidad OIDC es genuino?