Tanto SAML como OpenID Connect ofrecen inicio de sesión único (SSO), pero fueron diseñados para arquitecturas diferentes. Si elige el protocolo de autenticación incorrecto, tendrá que lidiar con análisis complejo de XML, problemas con la rotación de certificados o brechas en la integración con dispositivos móviles.

SAML 2.0 (estándar OASIS, 2005) se diseñó para la federación de identidades basada en XML en entornos empresariales. Las aplicaciones web tradicionales que se conectan a IdP empresariales son ejemplos clásicos. OpenID Connect (OpenID Foundation, 2014) amplía OAuth 2.0 con una capa de autenticación JSON ligera y optimizada para API, aplicaciones móviles y arquitecturas web modernas. La elección dependerá de la plataforma de destino y de la pila de identidad que ya tenga.

Ejemplo: Su empresa adquirió una empresa emergente. La aplicación React de dicha empresa debe ser compatible tanto con usuarios particulares que se autentican con Google (OIDC) como con empleados de su empresa que se autentican con el proveedor de identidad corporativa (SAML). Un IdP maneja ambos protocolos, por lo que su aplicación React mantiene un único punto de integración, en lugar de implementar flujos OIDC y SAML por separado.

Aspecto	SAML 2.0	OpenID Connect (OIDC)
Enfoque principal	Federación empresarial	Autenticación moderna con OAuth 2.0
Formato de datos	Afirmaciones XML con firmas digitales	Tokens web JSON (JWT) para tokens de ID
Base	Protocolo de autenticación y federación basado en XML	Capa de autenticación basada en OAuth 2.0
Transporte	Principalmente vinculaciones HTTP-POST y HTTP-Redirect (perfil de SSO del navegador)	HTTPS con redirecciones de canal frontal y llamadas directas al extremo de token/UserInfo
Configuración	Intercambio de metadatos XML, gestión de certificados	Registro de clientes mediante documentos de descubrimiento (.well-known/openid-configuration)
Formato de token	XML firmado (y opcionalmente cifrado)	JWT para tokens de ID; los tokens de acceso son específicos de la implementación (aunque OAuth 2.0/OIDC no exige tokens de acceso JWT, son cada vez más comunes)
Uso ideal	Entornos con requisitos heredados de federación gubernamental o regulados del sector	SPA, aplicaciones móviles, microservicios, inicio de sesión social
Complejidad de la integración	Nivel superior (análisis XML, gestión de metadatos, rotación de certificados)	Generalmente menor (análisis de JSON, llamadas HTTP simples, configuración detectable)

Diferencias esenciales más importantes. Las afirmaciones SAML pueden contener jerarquías de atributos complejas para requisitos empresariales complejos. OIDC usa ámbitos (openid, profile, email) para solicitar información específica en el token de ID y, opcionalmente, mediante el extremo UserInfo.

SAML funciona de forma independiente de OAuth 2.0. OIDC superpone la autenticación sobre los flujos de autorización de OAuth 2.0, lo que permite unificar la pila de protocolos para la autenticación y la autorización.

SAML (flujo iniciado por el SP). Su proveedor de servicios (SP) redirige a los usuarios al IdP mediante una solicitud de autenticación AuthnRequest. El IdP los autentica, genera una afirmación firmada con los atributos del usuario y la devuelve al Assertion Consumer Service (ACS) del SP mediante HTTP-POST. Usted valida la firma y las condiciones de la afirmación, y luego concede el acceso. Este flujo suele implicar varias redirecciones del navegador y una sobrecarga de procesamiento XML.

OIDC (flujo de código de autorización con PKCE). Su aplicación redirige a los usuarios al punto final de autorización del IdP con los ámbitos requeridos y un desafío de código PKCE. Tras la autenticación y el consentimiento, el IdP devuelve un código de autorización. Usted intercambia ese código (junto con el verificador PKCE) por un token de ID y un token de acceso, y puede recibir un token de actualización, según el tipo de cliente y la política del IdP. Valida la firma JWT y comprueba la información (iss, aud, exp), y eso es todo. Este flujo suele ser más sencillo de implementar gracias a la compatibilidad nativa con JSON/JWT en las plataformas modernas.

Adapte su arquitectura al protocolo adecuado.

Elija SAML en los siguientes casos:

• Integración con IdP empresariales vigentes
• Desarrollo para Gobiernos o sectores regulados que requieren FISMA, FedRAMP o federación basada en SAML heredada
• Sistemas que ya emplean SAML, donde los costos de cambiar superan los beneficios
• Gestión de requisitos complejos de atributos de usuario (jerarquías organizacionales anidadas, información personalizada)

Elija OIDC en los siguientes casos:

• Desarrollo de aplicaciones de una sola página (React, Vue, Angular) o aplicaciones móviles (iOS, Android)
• Incorporación de proveedores de inicio de sesión social (Google, GitHub, Apple)
• Creación de arquitecturas basadas en API o microservicios que requieren tokens de acceso OAuth 2.0
• Inicio desde cero sin restricciones heredadas, donde la configuración más sencilla de OIDC reduce el tiempo de puesta en producción
• Priorización de la experiencia del desarrollador con mejores bibliotecas y documentación

¿Y si necesita ambos? Los IdP pueden gestionar la mediación de protocolos. La aplicación usa OIDC al conectarse a IdP empresariales basados en SAML. Así, se evita tener que gestionar dos implementaciones de protocolo.

Validación del token

• Para OIDC, verifique las firmas JWT con el conjunto de claves web JSON (JWKS) publicado por el IdP, compruebe la caducidad (exp), valide que el público (aud) coincida con su ID de cliente y confirme que el emisor (iss) coincida con su IdP.
• Para SAML, verifique las firmas XML, compruebe las condiciones de caducidad (NotBefore, NotOnOrAfter) y valide las restricciones de público.

Configuración del cliente

Nunca incruste secretos de cliente en SPA ni en aplicaciones móviles; son visibles en las herramientas de desarrollo del navegador y en los códigos binarios de la aplicación. Use la clave de prueba para el intercambio de código (PKCE) para el flujo de códigos de autorización. La PKCE protege contra la interceptación de códigos de autorización sin necesidad de un secreto, que es obligatorio para clientes públicos (RFC 7636).

Gestión de sesiones

OIDC hereda la compatibilidad con tokens de actualización de OAuth 2.0 para sesiones de larga duración. Intercambie el token de actualización por nuevos tokens de acceso cuando caduquen, siempre que su IdP emita tokens de actualización y la configuración del cliente lo permita. SAML se basa en sesiones gestionadas por el IdP y el SP, en lugar de un mecanismo de actualización estandarizado, y es compatible con el cierre de sesión único (SLO) opcional, cuya implementación difiere entre los distintos IdP y puede resultar difícil de estandarizar.

Manejo de errores

Registre los errores de autenticación con contexto (marcas de tiempo, códigos de error, ID de cliente, respuestas del IdP) para la depuración. Muestre a los usuarios mensajes genéricos de “error de autenticación”. Evite exponer detalles de tokens, discrepancias en la información o errores de firma que puedan facilitar la labor de los atacantes.

¿Está OpenID Connect reemplazando a SAML?

No, ambos coexisten. La adopción de OIDC está creciendo rápidamente en aplicaciones para consumidores y en el desarrollo móvil debido a que se basa en OAuth 2.0. Sin embargo, SAML sigue siendo el estándar en el sector empresarial y gubernamental debido a las inversiones en infraestructura y a los requisitos de cumplimiento (FISMA, FedRAMP). La mayoría de las organizaciones usan ambos protocolos: OIDC para nuevas aplicaciones y SAML para la federación empresarial.

¿Qué protocolo es más seguro?

Ambos proporcionan una seguridad sólida cuando se implementan correctamente. SAML usa firmas XML y cifrado opcional; OIDC usa firmas JWT y HTTPS. La diferencia principal es que la extensión PKCE de OIDC (RFC 7636) protege a los clientes públicos, como las aplicaciones móviles y SPA, donde no se pueden proteger los secretos del cliente. SAML puede lograr protecciones similares mediante la vinculación de artefactos o las afirmaciones del poseedor de la clave, pero estos patrones son menos comunes en el desarrollo de aplicaciones modernas. La seguridad depende de la implementación, no del protocolo que se elija.

¿Por qué las aplicaciones móviles prefieren OIDC antes que SAML?

El flujo de código de autorización con PKCE de OIDC fue diseñado para clientes públicos, como aplicaciones móviles, que no pueden almacenar de forma segura los secretos del cliente. Los tokens JSON de OIDC se integran de forma nativa con los SDK para dispositivos móviles, mientras que SAML requiere bibliotecas de procesamiento XML. OIDC es compatible con esquemas URI personalizados (iOS) y enlaces de aplicaciones (Android) para una autenticación sin problemas. Los principales proveedores admiten mayormente flujos basados en OIDC para la autenticación móvil.

¿Cuál es la mejor ruta de migración de SAML a OIDC?

La migración incremental es la mejor opción. Implementar OIDC para aplicaciones nuevas manteniendo las integraciones SAML vigentes. Use una plataforma de identidad que admita la mediación de protocolos para que sus aplicaciones empleen OIDC al conectarse con IdP empresariales basados en SAML. Esto minimiza el riesgo sin interrumpir las relaciones de federación actuales. Muchas empresas mantienen entornos híbridos durante las fases de transición. Use una plataforma de identidad que gestione la mediación de protocolos y que permita que las aplicaciones usen OIDC mientras la plataforma gestiona la federación SAML.

¿Cuál es la diferencia entre OAuth 2.0 y OIDC?

OAuth 2.0 gestiona la autorización (acceso a las API) mediante tokens de acceso. OIDC agrega la autenticación (verificación de la identidad del usuario) mediante tokens de ID basados en OAuth 2.0. Al implementar el inicio de sesión con Google, se usa OIDC para la autenticación y OAuth 2.0 para el acceso a la API. OIDC amplía OAuth 2.0 con información de identidad estandarizada y el terminal UserInfo.

Elegir entre SAML y OIDC es fundamental para garantizar la seguridad de su arquitectura de autenticación. Ambos protocolos requieren una implementación cuidadosa, que incluye la validación adecuada de tokens, la gestión de certificados y el manejo de sesiones. Implementar y mantener ambos protocolos es un proceso complejo.

Auth0 es compatible con SAML y OIDC, y permite gestionar la mediación de protocolos y las prácticas recomendadas de seguridad para que los desarrolladores puedan centrarse en las funciones de la aplicación.

Explore nuestra serie de Introducción a la IAM para conocer más temas relacionados con la gestión de identidades y accesos.

Más información

Estos materiales tienen únicamente fines informativos generales. Usted es responsable de obtener orientación de seguridad, de privacidad, de cumplimiento o empresarial de sus propios asesores profesionales, y no debe confiar solamente en la información suministrada aquí.