Qué es SAML 2.0: flujo SSO, OAuth/OIDC y vulnerabilidades

SAML es el estándar XML que permite a un usuario autenticarse una vez en el IdP corporativo y acceder a múltiples aplicaciones sin volver a teclear credenciales. Las siglas vienen del inglés Security Assertion Markup Language. SAML 2.0 es la versión vigente desde 2005 y, pese a su edad y a la irrupción de OAuth 2.0 y OpenID Connect, sigue siendo la base del Single Sign-On en la mayoría de entornos corporativos: ADFS, Azure AD/Entra ID, Okta, Ping, Auth0, OneLogin y Salesforce hablan SAML.

Esta guía explica qué es SAML en concreto, cómo funciona el flujo SSO con IdP y SP, los componentes técnicos (assertions, bindings, profiles, metadata), comparación útil con OAuth 2.0, OIDC y JWT, las vulnerabilidades clásicas que aparecen en pentesting (XML Signature Wrapping, assertion replay, manipulación de NameID, sustitución de Issuer), mejores prácticas de configuración y cómo encaja en compliance NIS2, DORA, ISO 27001 y PCI DSS.

Qué es SAML

SAML es un estándar OASIS basado en XML que define cómo se intercambian datos de autenticación y autorización entre un proveedor de identidad y una o varias aplicaciones cliente. Resuelve el problema clásico de "tener que loguearse 30 veces al día": el usuario se autentica una vez contra el IdP corporativo y, a partir de ese momento, las aplicaciones que acepten assertiones SAML lo dejan entrar.

Los actores del protocolo:

• Identity Provider (IdP). Quien autentica al usuario y emite assertions firmadas. Ejemplos: Microsoft Entra ID, Active Directory Federation Services (ADFS), Okta, Ping Identity, Auth0, Keycloak.
• Service Provider (SP). La aplicación que confía en el IdP para autenticar a sus usuarios. Ejemplos: Salesforce, ServiceNow, Workday, Slack, GitHub Enterprise, aplicaciones SaaS y casi cualquier aplicación corporativa interna que soporte SSO.
• Asertion SAML. Documento XML firmado que el IdP emite y el SP valida. Contiene la identidad del usuario, atributos (rol, departamento, email), condiciones de validez y la firma digital.
• User Agent. El navegador del usuario, que actúa de intermediario en el flujo SSO.

Cómo funciona el flujo SSO con SAML

El flujo más usado en empresa (SP-Initiated, HTTP POST Binding) sigue siempre los mismos pasos:

1. El usuario abre la aplicación SaaS (https://app.example.com). El SP detecta que no hay sesión.
2. El SP construye una AuthnRequest SAML, la firma o cifra según política, la codifica en base64 y redirige al navegador del usuario al IdP corporativo (https://idp.empresa.com/sso).
3. El IdP valida la AuthnRequest, comprueba la sesión del usuario y, si no la hay, le pide credenciales (típicamente usuario y contraseña más MFA).
4. Tras la autenticación, el IdP construye una assertion SAML con la identidad y atributos del usuario, la firma con su clave privada y la entrega al navegador en una respuesta HTTP que contiene un formulario auto-submit hacia el SP.
5. El navegador hace POST al endpoint Assertion Consumer Service (ACS) del SP con la assertion firmada.
6. El SP verifica la firma usando el certificado público del IdP (que debe tener configurado), valida condiciones (timestamp, audience), extrae los atributos y crea sesión local.
7. El usuario está dentro de la aplicación sin haber tecleado nada en ella.

Existen variantes (IdP-Initiated, Redirect Binding, Artifact Binding) pero la mecánica esencial es la misma: el IdP firma, el SP verifica.

Componentes clave del estándar

Cuatro elementos cubren el grueso del trabajo técnico.

Asertions. El núcleo. Documentos XML firmados que afirman algo sobre el sujeto. Tres tipos:

• Authentication Assertion: el sujeto se autenticó en este momento usando este método.
• Attribute Assertion: el sujeto tiene estos atributos (email, rol, grupo).
• Authorization Decision Assertion: el sujeto está autorizado a hacer X (poco usada en SSO clásico).

Bindings. Cómo se transporta la assertion. Los más usados:

• HTTP Redirect: assertion en query string, comprimida. Para AuthnRequest cortas.
• HTTP POST: assertion en formulario auto-submit. El más común para assertions completas.
• HTTP Artifact: el SP recibe un identificador y consulta al IdP por SOAP para recuperar la assertion. Más seguro pero menos compatible.

Profiles. Combinaciones de bindings y assertions para casos concretos. El más usado: Web Browser SSO Profile.

Metadata. XML público que cada parte expone con su configuración (URLs, certificados, atributos requeridos). El SP y el IdP intercambian metadata al darse de alta y se actualizan periódicamente.

SAML frente a OAuth 2.0, OIDC y JWT

La confusión entre estos protocolos es habitual. Las diferencias prácticas:

• SAML está pensado para autenticación SSO en aplicaciones empresariales, basado en XML, assertions firmadas. Domina en B2B y en herramientas corporativas.
• OAuth 2.0 está pensado para autorización delegada: una aplicación accede a recursos de otra en nombre del usuario sin que este comparta credenciales. Tokens JSON, no XML.
• OpenID Connect (OIDC) se construye sobre OAuth 2.0 y añade autenticación. Domina en aplicaciones móviles, SPAs modernas y APIs.
• JWT es el formato de token usado por OAuth 2.0 y OIDC, también por aplicaciones web modernas para sesiones stateless. Independiente del protocolo.

Cuándo elige cada uno una organización:

• Aplicaciones SaaS corporativas legacy: SAML por compatibilidad. Sigue siendo el formato más extendido en RFPs B2B.
• Aplicaciones móviles, SPAs o APIs públicas: OIDC por simplicidad y soporte nativo en SDKs modernos.
• Aplicaciones internas que el equipo controla por completo: OIDC casi siempre, salvo que ya haya IdP SAML rentabilizado.
• Federaciones grandes (universidades, gobierno, sanidad): SAML mantiene presencia fuerte por inercia institucional.

En 2026 muchas empresas operan IdPs híbridos (Entra ID, Okta, Auth0) que hablan los dos protocolos al mismo tiempo y dejan que cada SP elija. La tendencia es OIDC para todo lo nuevo y SAML para lo legacy.

Vulnerabilidades habituales en pentesting

SAML es uno de los blancos más rentables en una auditoría web profesional. Las vulnerabilidades clásicas siguen apareciendo en producción. En auditorías de SPs en producción, XSW y la ausencia de validación de Issuer son los dos hallazgos que más se repiten en SPs antiguos o construidos con librerías sin actualizar.

XML Signature Wrapping (XSW)

La assertion SAML se firma criptográficamente, pero la firma se aplica a una sección concreta del XML. Si el SP valida la firma sobre una sección y luego procesa información de otra sección distinta, el atacante puede empaquetar dos assertions en el mismo documento: la firmada (con datos legítimos) y otra inyectada (con datos del atacante). Bien construido, el SP valida la firmada y procesa la inyectada.

Hay ocho variantes documentadas (XSW1 a XSW8). Auditarlas a mano es costoso; herramientas como SAML Raider (Burp Suite extension) automatizan la generación de payloads.

XML External Entities (XXE)

Si el parser XML del SP procesa entidades externas, el atacante incluye en la assertion referencias a ficheros locales (/etc/passwd, file:///c:/windows/win.ini) o a URLs internas. El SP las resuelve y devuelve el contenido o lanza una conexión SSRF al backend.

Defensa: configurar el parser XML para deshabilitar resolución de entidades externas. Lenguajes y librerías modernas suelen tenerlo deshabilitado por defecto, pero código legacy en Java, Python o .NET sigue siendo vulnerable.

Manipulación del NameID o atributos

Si el SP confía en el NameID o en atributos como Email para identificar al usuario sin validar adecuadamente, un atacante con control sobre alguno de esos campos puede suplantar identidad. Casos típicos:

• IdP configurado para enviar Email y SP que crea cuenta nueva o asocia a cuenta existente sin doble verificación.
• Aplicaciones con NameID transitorio donde se asume persistente.
• Mapeo de atributos custom sin validación de formato.

Asertion Replay

Si el SP no marca assertions como usadas tras consumirlas, un atacante que intercepta una assertion legítima puede reusarla dentro de la ventana de validez (NotOnOrAfter típicamente 5 minutos). Defensa: cache de identificadores de assertion ya consumidas, validación estricta de timestamps y Audience.

Bypass de firma con <ds:Signature> aleatoria

Algunos SPs aceptan assertions con elemento <Signature> presente pero no validado realmente, o aceptan elementos <Signature> insertados en posiciones inesperadas del XML. Variante específica de XSW que merece auditoría dedicada.

Sustitución del Issuer

El SP debe validar que el Issuer de la assertion coincide con el IdP confiado. Si no lo hace, un atacante con su propio IdP puede emitir assertions y enviarlas al SP víctima. Este fallo apareció en versiones antiguas de varias librerías, incluyendo casos públicos en GitHub Enterprise (2017) y otras plataformas.

Vulnerabilidades históricas notables

• CVE-2017-11427 y familia: bypass de autenticación SAML en múltiples librerías (OneLogin Ruby SAML, Clever-Tools), comentarios XML mal procesados que hacían que el parser viera un NameID y la firma viera otro.
• CVE-2020-14322 (mod_auth_mellon): bypass por uri parsing.
• CVE-2024-39689 (xml-crypto): variante moderna de XSW.

Cada release de un parser XML tiene potencial de introducir nuevas variantes. Mantener la librería actualizada es necesario pero no suficiente; revisar el código de validación a mano sigue siendo parte de cualquier auditoría seria.

Mejores prácticas de configuración

Las que aplican equipos serios cuando despliegan o auditan SAML en producción.

• Firmar tanto assertions como respuestas SAML (no solo assertions). Algunas configuraciones firman uno pero no el otro y dejan superficie abierta.
• Forzar TLS 1.2+ en bindings HTTP. Aunque la assertion vaya firmada, el TLS protege la confidencialidad de los atributos.
• Validar Issuer, Audience, NotOnOrAfter, NotBefore, Recipient, Destination en cada respuesta. Cualquiera que se omita es vector.
• Cache de assertion IDs ya consumidas durante toda la ventana de validez (mejor: mucho más allá).
• Rotación de certificados de firma del IdP con periodo razonable. Mantener al SP actualizado vía metadata fresca.
• MFA obligatorio en el IdP. La promesa de SAML SSO se rompe si el login original es solo contraseña.
• Logs centralizados de eventos SSO. Detección de logins anómalos, assertions con destino inesperado, errores recurrentes.
• Revisión periódica de aplicaciones que confían en el IdP. Quitar SPs olvidados de la lista de relaciones de confianza.
• Validar parser XML contra XXE, XSW y variantes con tests automatizados en CI/CD.

Detalle operativo en una auditoría web profesional.

Encaje con compliance

SAML mal configurado o desactualizado materializa riesgos cubiertos por marcos vigentes:

• NIS2 (artículo 21). Control de accesos, autenticación, gestión de identidades. Una vulnerabilidad SAML que permita suplantación es incumplimiento defendible ante auditoría.
• DORA (artículo 9). Resiliencia ICT en servicios financieros. Las federaciones SAML entre entidades exigen control formal.
• ISO 27001:2022 (controles 5.16, 8.5, 8.26). Gestión de identidades, autenticación segura, requisitos de seguridad de aplicaciones.
• ENS Real Decreto 311/2022. Medidas op.acc (control de acceso) y op.exp.10 (protección de información en tránsito).
• PCI DSS v4.0 (req. 7, 8). Control de acceso y autenticación para entornos que procesen datos de tarjeta.
• RGPD. Vulnerabilidades SAML que filtren datos personales en assertions o permitan acceso indebido son brechas notificables.

Preguntas frecuentes

¿Qué diferencia hay entre SAML y SSO?

SSO es el concepto: autenticarse una vez para acceder a varias aplicaciones. SAML es un protocolo que implementa SSO. Otros protocolos también lo implementan (OIDC, Kerberos en Active Directory, CAS). En empresa la palabra "SSO" suele referirse a SAML por inercia, pero técnicamente son cosas distintas.

¿SAML está obsoleto frente a OIDC?

No. Está más maduro y más implementado. OIDC es más moderno, más simple y mejor para móviles y SPAs, pero SAML sigue siendo dominante en SaaS corporativo y en federaciones académicas/gubernamentales. La mayoría de empresas operan los dos en paralelo.

¿Por qué SAML usa XML cuando todo lo nuevo usa JSON?

Porque se diseñó en 2003-2005 cuando XML era la opción estándar para datos firmados. La firma digital sobre XML (XML Signature) está bien especificada y ampliamente implementada, aunque sea verbosa. OIDC eligió JWT (JSON) por simplicidad, lo que también introdujo otros problemas (algoritmo none, confusión de tipos).

¿Es seguro el flujo IdP-Initiated?

Es más débil que SP-Initiated. Sin la AuthnRequest previa firmada, el SP no puede verificar que el flujo se inició por el usuario legítimo. Permite ataques de unsolicited response replay. La recomendación moderna es preferir SP-Initiated y deshabilitar IdP-Initiated cuando no sea estrictamente necesario.

¿Cómo audito una integración SAML existente?

Tres pasos básicos: 1) revisión de configuración del SP (qué valida, qué ignora, qué bindings acepta); 2) tests automatizados con herramientas como SAML Raider, samlpy o test suites OWASP; 3) revisión manual del parser XML y de la lógica que mapea assertion a sesión. Es trabajo especializado que en empresa media suele requerir auditor externo.

¿Qué pasa si el certificado del IdP caduca?

Toda autenticación SAML deja de funcionar inmediatamente. La rotación de certificados es uno de los puntos más comunes de incidente operacional. La buena práctica es: período de doble certificado activo, monitorización de fecha de caducidad, automatización de actualización de metadata en SPs.

¿SAML protege contra ataques de phishing?

Solo parcialmente. Si el atacante suplanta la página del IdP y el usuario teclea credenciales, SAML no ayuda. La defensa real frente a phishing en flujos SSO es MFA fuerte resistente a phishing (FIDO2/WebAuthn) en el login del IdP, no el protocolo en sí.

Recursos relacionados

• Qué es JWT y seguridad de tokens: el formato de token usado por OAuth 2.0/OIDC, alternativa moderna a SAML.
• Qué es PKI: infraestructura de certificados subyacente a la firma SAML y a TLS.
• Pentesting de aplicaciones web: el contexto donde aparecen sistemáticamente vulnerabilidades SAML.
• Pentesting de APIs REST y GraphQL: donde el patrón equivalente con OAuth/OIDC se audita.
• OWASP Top 10 2025: la categoría A07 Identification and Authentication Failures cubre fallos SAML.
• CORS: control complementario en aplicaciones SPA modernas que combinan SSO con APIs cross-origin.

Auditoría SAML en Secra

En Secra revisamos la implementación SAML como parte estándar de cualquier auditoría web profunda: validación contra los 8 vectores XSW, comprobación de validación de Issuer/Audience/timestamps, test del parser XML frente a XXE, revisión de mapeo NameID-a-sesión, evaluación de resiliencia frente a replay y revisión de configuración del IdP (firma de respuestas, MFA obligatorio, logs). Si tu organización tiene IdP propio (ADFS, Keycloak) o federación con varios SPs corporativos y nunca se ha auditado el flujo SSO, escríbenos a través de contacto o consulta nuestro servicio de auditoría web y móvil.