SSO y Federación: SAML y OIDC
Arquitecturas de Single Sign-On, SAML 2.0, OpenID Connect y OAuth 2.0
¿Qué es SSO?
Single Sign-On permite al usuario autenticarse una sola vez con su Identity Provider (IdP) y acceder a múltiples aplicaciones (Service Providers / Relying Parties) sin volver a introducir credenciales.
Beneficios de seguridad
- • Un solo punto para aplicar MFA y políticas
- • Eliminación de credenciales por aplicación (menos phishing surface)
- • Deprovisioning centralizado: baja a alguien en 1 lugar → accede a 0 apps
- • Logs de autenticación unificados
Riesgos a considerar
- • IdP es un Single Point of Failure — alta disponibilidad obligatoria
- • Si el IdP es comprometido, todas las apps quedan expuestas
- • Session hijacking del token SSO puede dar acceso total
SAML 2.0
Security Assertion Markup Language (OASIS 2005). Basado en XML. Estándar dominante en entornos empresariales (Okta, Azure AD, PingFederate, ADFS).
Principal
El usuario final que quiere acceder
Identity Provider (IdP)
Autentica al usuario y emite assertions. Okta, Azure AD, Auth0
Service Provider (SP)
La aplicación que el usuario quiere usar. Salesforce, Office 365
Flujo SP-Initiated (más común):
1. Usuario → app.salesforce.com (sin sesión)
2. SP genera AuthnRequest XML, redirige al IdP
3. IdP autentica usuario (user/pass + MFA)
4. IdP genera SAML Assertion (XML firmado con clave privada)
5. IdP POST assertion al SP vía navegador del usuario
6. SP verifica firma con clave pública del IdP
7. SP crea sesión local ✅
<!-- SAML Assertion simplificada -->
<saml:Assertion Version="2.0">
<saml:Issuer>https://idp.empresa.com</saml:Issuer>
<saml:Subject>
<saml:NameID>alice@empresa.com</saml:NameID>
</saml:Subject>
<saml:AuthnStatement AuthnInstant="2024-01-15T10:00:00Z" />
<ds:Signature>...firma digital XML...</ds:Signature>
</saml:Assertion>
Vulnerabilidades SAML conocidas
- • XML Signature Wrapping (XSW): manipular el XML para que la firma válida envuelva datos maliciosos
- • Replay attacks: reutilizar una assertion válida antes de que expire
- • Mitigación: validar InResponseTo, NotBefore/NotOnOrAfter, y verificar la firma en los elementos correctos
OpenID Connect (OIDC)
OIDC es una capa de identidad sobre OAuth 2.0. OAuth 2.0 solo resuelve autorización (acceso a APIs); OIDC añade autenticación emitiendo un ID Token (JWT) que identifica al usuario.
OAuth 2.0 vs OIDC — la diferencia clave
OAuth 2.0
"Esta app puede leer tus Google Drive files" — Access Token para APIs
OIDC
"El usuario que inició sesión es alice@gmail.com" — ID Token (JWT) con claims del usuario
Authorization Code Flow (el más seguro):
1. App redirige al Authorization Server (AS) con response_type=code
2. Usuario se autentica en el AS
3. AS redirige de vuelta con ?code=AUTH_CODE
4. App intercambia código por tokens (server-side, no expuesto al browser)
5. AS devuelve: access_token + id_token (JWT) + refresh_token
# PKCE (RFC 7636) obligatorio para SPAs y apps móviles
// ID Token (JWT) decodificado
{
"iss": "https://accounts.google.com",
"sub": "110248495801234567890",
"aud": "client_id_de_tu_app",
"exp": 1705312800,
"iat": 1705309200,
"email": "alice@empresa.com",
"email_verified": true
}
Buenas Prácticas
Usar Authorization Code Flow + PKCE para cualquier app pública (SPA, móvil).
Validar siempre iss, aud, exp, iat del ID Token — nunca confiar en el JWT sin verificar firma.
No usar el Access Token para identificar al usuario; usar el ID Token o el endpoint /userinfo.
Configurar Redirect URIs exactos (sin wildcards) para evitar open redirects.
Implementar PKCE (code_challenge) para mitigar interception attacks del authorization code.
Rotar refresh tokens y revocarlos en logout; implementar token binding donde sea posible.
Siguiente Paso
Entiende los tipos de firewalls y cómo diseñar arquitecturas de red seguras
Firewalls y Arquitecturas de Red →