SAML: Un fractal de mal diseño
SAML, el estándar de inicio de sesión único basado en XML y muy usado en empresas, recibe cada vez más críticas por ser excesivamente complicado, inseguro y producto de un diseño por comité difícil de implementar correctamente. Los comentaristas lo contrastan con OAuth2/OpenID Connect y JWT, vistos como más simples y seguros, aunque aún imperfectos y afectados por su propio ecosistema e incentivos comerciales como el “impuesto SSO.” Muchos sostienen que, aunque SAML persiste por la inercia empresarial y los IdP heredados, los productos nuevos deberían preferir OIDC cuando sea posible y tratar SAML como tecnología heredada que debe retirarse gradualmente.
Demanda empresarial vs. elección del proveedor
- Muchos sostienen que los productos empresariales deben soportar cualquier SSO que usen sus clientes (a menudo SAML); de lo contrario, simplemente no son viables.
- Otros responden que los proveedores no están obligados a adoptar protocolos que consideran inseguros; perder a esos clientes es una decisión comercial, no una obligación.
- Algunos proveedores informan que pasaron a ser solo OIDC y, en la práctica, la mayoría de los “clientes SAML” aceptó cambiar porque sus IdP ya soportaban OIDC.
- Ángulo económico: las funciones de SAML a menudo están detrás de un pago (“impuesto SSO”), con proveedores que cobran miles por “activar el interruptor”, justificado por costos de soporte y mantenimiento.
SAML vs OIDC/OAuth2/JWT
- Hay amplio consenso en que SAML es más complejo y frágil que OAuth2/OIDC y JWT, aunque OAuth2/OIDC/JWT también tienen trampas no triviales.
- Debate sobre si “OAuth2 es una mierda” proviene de usarlo para autenticación en lugar de autorización; OIDC se presenta como la capa correcta de authN.
- Algunos afirman que SAML probablemente sobrevivirá a OIDC debido a la inercia empresarial; otros abogan por tratar SAML como un legado obsoleto (p. ej., IE6) que debe retirarse gradualmente.
Problemas de seguridad e implementación
- Las firmas XML de SAML son un foco importante: las firmas pueden cubrir subconjuntos elegidos por el atacante, dependen de la canonicalización y son vulnerables a XML Signature Wrapping.
- Históricamente, muchas implementaciones validaban una firma y luego confiaban en todo el documento, o usaban mal bibliotecas de XML-sig (p. ej., HMAC con claves proporcionadas por el atacante, validación WebPKI).
- Problemas de JWT/JOSE discutidos:
alg:none, confusión de algoritmos, mezcla de claves simétricas y asimétricas. Aun así, muchos participantes ven los problemas de JWT como menos numerosos y más fáciles de mitigar que los de SAML.
Flujos iniciados por IdP vs iniciados por SP
- Algunos defienden SAML por el SSO iniciado por IdP y por la “seguridad incorporada en la carga útil”, especialmente en escenarios de portal empresarial.
- Otros señalan que los flujos iniciados por IdP son susceptibles a login CSRF; OIDC los evita intencionalmente, usando en su lugar flujos iniciados por terceros que siguen comenzando en el SP.
- Hay desacuerdo sobre si los mensajes de confirmación al usuario mitigan de forma significativa tales ataques.
XML, complejidad y diseño por comité
- Varios comentarios culpan de los problemas de SAML a XML más el diseño por comité: demasiadas opciones para firma/cifrado y un tamaño de especificación extremo.
- Se hacen comparaciones con OSI vs IP, OpenVPN vs WireGuard y XML vs JSON como ejemplos de que los diseños más simples y opinados suelen funcionar mejor.
Identidad federada, “impuesto SSO” y alternativas
- Se citan OpenID original, el descubrimiento y registro dinámicos de OpenID Connect, IndieAuth y DID/FedCM como bloques para una identidad independiente del proveedor.
- El consenso del hilo: los incentivos comerciales (acaparamiento de datos, venta adicional de SSO) y no la falta de tecnología son lo que bloquea el inicio de sesión federado generalizado.
- Algunos sugieren que, en la práctica, las inconsistencias de SCIM ahora consumen más esfuerzo que las cuestiones de protocolo SAML vs OIDC.