SAML frente a OIDC: protocolos de inicio de sesión único

SAML frente a OIDC es la decisión de protocolo que hay detrás del inicio de sesión único. En SAML 2.0 (estándar de OASIS, marzo de 2005), un proveedor de identidad firma una aserción XML sobre el usuario y el navegador la lleva al proveedor de servicios. OpenID Connect (Core 1.0, febrero de 2014, también ISO/IEC 26131:2024) añade una capa de identidad sobre OAuth 2.0: el proveedor emite un JWT firmado, el token de ID, normalmente mediante el flujo de código de autorización, y en el mismo intercambio puede emitir tokens de acceso para API.

De un vistazo

Cómo inicia sesión el usuario en cada uno

En SAML, el proveedor de servicios redirige el navegador al proveedor de identidad con una solicitud AuthnRequest. Tras el inicio de sesión, el IdP devuelve un formulario HTML que envía por POST un mensaje Response codificado en base64 con la aserción: emisor, sujeto, restricción de audiencia, período de validez, atributos y una firma XML. El proveedor de servicios verifica la firma con el certificado de los metadatos del IdP y comprueba las condiciones.

En OpenID Connect, el cliente redirige al endpoint de autorización del proveedor con scope=openid, un state, un nonce y un desafío PKCE. El proveedor devuelve un código de un solo uso a la URI de redirección; el cliente lo canjea en el endpoint de token por el token de ID y el token de acceso a través de una conexión TLS directa, de modo que los tokens nunca pasan por la barra de direcciones del navegador.

El script siguiente lee los dos tipos de configuración del mismo proveedor (20 de octubre de 2026, curl y jq 1.8.1). En descargas repetidas, el tamaño de los metadatos SAML varió entre 28 y 32 KB y el del JWKS, entre 7 y 8 claves, según el servidor que respondía.

#!/bin/sh
base=https://login.microsoftonline.com/common
echo "== OpenID Connect discovery"
curl -s "$base/v2.0/.well-known/openid-configuration" -o oidc.json
echo "bytes: $(wc -c < oidc.json | tr -d ' ')"
jq -c '{id_token_signing_alg_values_supported, response_types_supported}' oidc.json
curl -s "$(jq -r .jwks_uri oidc.json)" | jq -c '{jwks_keys: (.keys | length), kty: ([.keys[].kty] | unique)}'

echo "== SAML 2.0 metadata"
curl -s "$base/FederationMetadata/2007-06/FederationMetadata.xml" -o saml.xml
echo "bytes: $(wc -c < saml.xml | tr -d ' ')"
grep -o 'SignatureMethod Algorithm="[^"]*"' saml.xml | sort -u
grep -o 'SingleSignOnService Binding="[^"]*"' saml.xml | sort -u
echo "distinct certificates: $(grep -o '<X509Certificate>[^<]*' saml.xml | sort -u | wc -l | tr -d ' ')"
rm -f oidc.json saml.xml

== OpenID Connect discovery
bytes: 1728
{"id_token_signing_alg_values_supported":["RS256"],"response_types_supported":["code","id_token","code id_token","id_token token"]}
{"jwks_keys":7,"kty":["RSA"]}
== SAML 2.0 metadata
bytes: 28179
SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
distinct certificates: 5

Qué debe comprobar la relying party

SAML: verifica la firma XML con el certificado del IdP que tienes configurado (nunca con uno incrustado en el mensaje) y asegúrate de que la firma cubre exactamente la aserción que lee tu código; después comprueba Issuer, Destination, InResponseTo, AudienceRestriction, NotBefore y NotOnOrAfter, y rechaza los mensajes reutilizados. La dificultad es estructural. XML Signature firma elementos referenciados por su ID después de la canonicalización, de modo que un documento puede contener un elemento con una firma válida y otro distinto, sin firmar, que la aplicación procesa en su lugar. En 2012, Somorovsky y sus colegas demostraron este tipo de signature wrapping (envoltura de firmas) en 11 de 14 frameworks de SAML; en 2024 y 2025, ruby-saml (utilizada por GitLab) volvió a necesitar correcciones (CVE-2024-45409, CVE-2025-25291 y CVE-2025-25292) porque dos analizadores XML de la misma biblioteca interpretaban un mismo documento de forma distinta.

OpenID Connect (Core §3.1.3.7): verifica el JWS con una clave del JWKS del proveedor, seleccionada según el kid, y con el algoritmo que esperas; después comprueba iss, aud (tu ID de cliente), exp, iat y el nonce de tu solicitud. JSON tiene un único árbol de análisis y la firma cubre exactamente los bytes recibidos, así que el problema del signature wrapping no existe; los escollos que quedan son aceptar algoritmos inesperados, omitir la comprobación de aud y una comparación laxa de las URI de redirección, de los que se ocupan las mejores prácticas actuales de seguridad de OAuth (RFC 9700, enero de 2025). El validador de tokens de ID de OIDC ejecuta estas comprobaciones con el JWKS en vivo de un proveedor, y el inspector de SAML muestra qué elemento cubre realmente una firma.

Cuándo elegir cada uno

• Aplicaciones nuevas, aplicaciones móviles, aplicaciones de una sola página, API: OpenID Connect con el flujo de código y PKCE.
• Venta de SaaS a empresas: admite ambos; los equipos de identidad de muchos clientes siguen configurando SAML en primer lugar.
• Federaciones de investigación y educación (eduGAIN, InCommon): SAML, con agregados de metadatos; OpenID Federation 1.0 (versión final desde febrero de 2026) está en fase piloto en eduGAIN, pero todavía no es la norma.
• Administración pública y sectores regulados: sigue el perfil que exija tu ecosistema; la banca abierta (open banking) y regímenes similares usan FAPI 2.0, un perfil reforzado de OAuth y OpenID Connect.
• Aprovisionamiento de usuarios y grupos: ninguno de los dos; usa SCIM 2.0 (RFC 7643 y RFC 7644) junto con cualquiera de los dos protocolos.

Notas de migración

1. Ejecuta ambos en paralelo: configura una aplicación OIDC en el mismo proveedor de identidad y asocia el mismo identificador de usuario (sub o un atributo estable) a las cuentas existentes antes del cambio.
2. Asigna los atributos a claims (declaraciones) de forma explícita; los nombres de atributo de SAML (a menudo URN) rara vez coinciden con los nombres de claim de OIDC, y los claims de grupo pueden requerir una llamada a la API aparte cuando los usuarios pertenecen a muchos grupos.
3. Usa una biblioteca certificada para OpenID Connect, activa el descubrimiento y la caché del JWKS con actualización ante un kid desconocido, y fija los algoritmos aceptados.
4. Refuerza lo que siga en SAML: actualiza la biblioteca, exige aserciones firmadas, rechaza los documentos con varias aserciones o con DTD y vigila la caducidad de los certificados en los metadatos de los socios.
5. Planifica el cierre de sesión por separado: haz corresponder el Single Logout de SAML con el Back-Channel Logout de OIDC donde las sesiones deban terminar de forma centralizada.
6. Retira la conexión SAML solo cuando los registros no muestren ningún inicio de sesión SAML durante un ciclo de negocio completo.

Referencias

• OASIS SAML 2.0 Core y Bindings
• OpenID Connect Core 1.0 (§3.1.3.7, validación del token de ID)
• OpenID Connect Discovery 1.0
• OpenID Connect Back-Channel Logout 1.0
• RFC 9700, mejores prácticas actuales de seguridad de OAuth 2.0
• RFC 7636, PKCE y RFC 8252, OAuth para aplicaciones nativas
• XML Signature Syntax and Processing 1.1, recomendación del W3C
• Somorovsky et al., «On Breaking SAML», USENIX Security 2012