Security Assertion Markup Language, o SAML, sigue ampliamente utilizado para el inicio de sesión único empresarial porque ofrece al proveedor de identidad una forma estándar de indicar al proveedor de servicios que un usuario se ha autenticado. El proveedor de servicios puede tomar entonces una decisión de acceso sin gestionar las credenciales originales del usuario. Esa separación resulta útil para las organizaciones que operan muchas aplicaciones en la nube, pero también hace que la corrección del intercambio de aserciones sea crítica: una aserción falsificada o interpretada incorrectamente puede convertirse en una vulneración de la autenticación.
Trail of Bits sostiene que la debilidad central de SAML no es simplemente un fallo histórico aislado. El protocolo está construido sobre XML, un formato flexible con espacios de nombres, atributos, comentarios, esquemas, secciones CDATA y otras construcciones que las implementaciones deben analizar de manera coherente. Su seguridad depende de la validación de firmas XML, la canonicalización y el acuerdo entre el proveedor de identidad y el proveedor de servicios sobre qué datos cubre la firma. El ensayo identifica los ataques de envoltura de firmas, las diferencias entre analizadores y los errores de canonicalización como ejemplos recurrentes de cómo dos implementaciones pueden discrepar sobre el significado del mismo mensaje.
Esta figura respalda directamente la explicación del artículo sobre la validación de firmas XML y los fallos de canonicalización.
La distinción entre un fallo del protocolo y un fallo de implementación es importante. SAML define un amplio conjunto de mensajes, enlaces y perfiles, mientras que las implementaciones reales suelen utilizar solo un subconjunto. Esto puede dejar una superficie de la especificación sin utilizar en bibliotecas y código de configuración, pero no demuestra que cada implementación desplegada sea vulnerable. Un producto solo puede admitir SAML de forma segura si valida las firmas, las restricciones de audiencia y destinatario, la sincronización, la identidad del emisor y la aserción firmada exacta de acuerdo con la política pertinente del despliegue. El material suministrado no demuestra que todos los productos SAML fallen en esas comprobaciones.
El ensayo también critica las firmas envueltas de SAML, en las que el elemento de firma se coloca dentro de la aserción XML que está firmando. Lo contrasta con la estructura de firma desligada comúnmente asociada con los JSON Web Tokens, al tiempo que reconoce que cambiar a otro formato de token no elimina automáticamente los problemas de validación. OIDC se basa en una familia más amplia de especificaciones e implementaciones, y el paquete no aporta pruebas primarias suficientes para comparar su tasa de vulnerabilidad en el mundo real con la de SAML. Por tanto, las afirmaciones de que OIDC es categóricamente más seguro siguen siendo un argumento que debe investigarse, no una conclusión demostrada.
Esta comparación ilustra el análisis del artículo sobre las firmas envueltas de SAML y su contraste con las firmas JWT.
Para los operadores, la pregunta más útil es si su despliegue cuenta con una configuración estrecha y bien probada, y con una biblioteca mantenida. Trail of Bits sugiere rechazar formas de mensaje inesperadas y evitar, cuando sea posible, funciones innecesarias del protocolo. Las organizaciones también deberían inventariar todos los proveedores de identidad, proveedores de servicios, conectores personalizados e integraciones heredadas que aceptan aserciones SAML y comprobar cómo cada uno maneja las firmas y los casos límite del analizador. Un proyecto de migración debería conservar esos controles en lugar de tratar un cambio de protocolo como un sustituto de una configuración segura.
OIDC puede ser una alternativa razonable para nuevas integraciones web, especialmente cuando su flujo de código de autorización y la comunicación por canal secundario encajan con la arquitectura. Sin embargo, las pruebas suministradas no muestran que admita por igual todos los patrones de implementación de SAML, ni establecen una ruta de migración universal. Los equipos con flujos iniciados por el proveedor de identidad, suposiciones de red desconectada o requisitos empresariales especializados deben probar explícitamente la compatibilidad. Puede ser necesario admitir ambos protocolos durante una transición, pero cada protocolo admitido añade trabajo de configuración y validación.
La lección más amplia es que los protocolos de autenticación envejecen tanto a través de sus especificaciones como de sus implementaciones. La longevidad de SAML refleja un valor genuino de interoperabilidad y despliegue; no hace que su complejidad sea inocua. A la inversa, identificar fallos repetidos en el procesamiento de XML y firmas no justifica afirmar que cada inicio de sesión con SAML es inseguro. Los equipos de seguridad deben tratar el protocolo como una dependencia que implica riesgos, reducir la flexibilidad innecesaria, mantener las bibliotecas actualizadas y exigir pruebas de que el flujo desplegado exactamente se ha probado frente a ataques conocidos de analizadores y firmas.