SAML es un protocolo de autenticación y federación que permite usar Single Sign-On (SSO) en las empresas. OAuth 2.0 es un marco de autorización que concede acceso delegado a las API mediante tokens de acceso.

La autenticación y la autorización son la base de la gestión de identidades y accesos (IAM), pero los protocolos que las habilitan (como SAML y OAuth 2.0) cumplen propósitos diferentes, aunque relacionados. Combinarlos genera brechas de seguridad y riesgos innecesarios en la arquitectura.

Ejemplo: Su empresa usa Salesforce, Slack y un portal interno de RR. HH. Con SAML, inicia sesión una vez en su directorio corporativo y se autentica inmediatamente en los tres (SSO empresarial). Cuando quiere permitir que una herramienta de análisis de terceros acceda a sus datos de Salesforce sin compartir su contraseña, usa OAuth 2.0, que delega autorizaciones a recursos específicos.

SAML 2.0:

• Autentica a los usuarios y habilita el SSO empresarial
• Responde la pregunta “¿Quién es este usuario?”
• Utiliza afirmaciones XML con atributos de identidad
• Optimizado para federación empresarial y SSO de la fuerza laboral

OAuth 2.0:

• Autoriza el acceso a recursos sin compartir credenciales
• Responde la pregunta “¿A qué puede acceder este usuario?”
• Emite tokens de acceso (y, opcionalmente, tokens de actualización) para la autorización de la API
• Optimizado para seguridad de la API, aplicaciones móviles y acceso de terceros

OpenID Connect (OIDC) es una capa de identidad basada en OAuth 2.0 que agrega autenticación mediante tokens de identificación.

Si bien ambos son estándares abiertos, sus propósitos difieren. SAML 2.0 se centra en la autenticación (AuthN) y en SSO al responder la pregunta “¿Quién es este usuario?”. En cambio, OAuth 2.0 se centra en la autorización (AuthZ) al responder la pregunta “¿A qué puede acceder este usuario?”.

SAML se diseñó para la federación de identidades en contextos empresariales y gubernamentales. OAuth 2.0 es un marco de autorización diseñado para delegar acceso y suele usarse para proteger API modernas y aplicaciones de consumo.

• SAML 2.0 (estándar OASIS, 2005)
• OAuth 2.0 (IETF RFC 6749, 2012)
• OpenID Connect (OpenID Foundation, 2014)

Aspecto	SAML 2.0	OAuth 2.0
Objetivo principal	Autenticación y SSO empresarial	Autorización y acceso delegado
Formato de datos	XML (afirmación de seguridad)	OAuth 2.0 no depende del formato del token; la mayoría de las implementaciones usan JWT, aunque también se admiten tokens opacos
Elementos clave	Afirmaciones XML firmadas, metadatos de federación (fuera de banda)	Tokens de acceso, ámbitos
Transferencia de identidad	Incorporada: Las afirmaciones contienen explícitamente atributos de identidad (p. ej., rol, correo electrónico)	No incorporada: Los tokens de acceso solo proporcionan autorización; OpenID Connect agrega atributos de identidad
Adopción	Identidad de la fuerza laboral empresarial, sistemas heredados	API, aplicaciones móviles/nativas, microservicios
Complejidad del token	Alta (análisis XML, firmas digitales)	Moderada (los JWT requieren validación de firma, atributo y ciclo de vida de claves; los tokens opacos requieren introspección)

SAML usa XML para sus afirmaciones de seguridad. XML requiere una sobrecarga adicional para el análisis y la validación de firmas, lo que genera tamaños de mensaje más grandes que pueden afectar el desempeño en entornos de alto rendimiento.

OAuth 2.0 no define el formato del token. Los tokens web JSON (JWT) son comunes, pero no obligatorios. Los JWT son compactos y ligeros, y suelen validarse mediante la verificación de firmas, la validación de atributos y la rotación de claves. Esto los hace ideales para aplicaciones móviles y para escalar la autorización de API. Si se emplean tokens opacos, la validación se realiza mediante la introspección del token en lugar de utilizar comprobaciones locales de firmas.

La distinción básica radica en lo que prueba el elemento central de cada protocolo.

Las afirmaciones de SAML son una declaración directa de la identidad y los atributos de un usuario emitida por un proveedor de identidades (IdP). Una aplicación puede confiar en la afirmación para confirmar la identidad del usuario y los grupos a los que pertenece.

Los tokens de acceso de OAuth 2.0 solo obtienen la autorización para acceder a un recurso específico. El token no es una prueba de identidad. Usar solo OAuth 2.0 para la autenticación, sin una extensión como OIDC, crea una brecha de seguridad, pues el token de acceso no verifica la identidad del usuario.

La diferencia fundamental entre los protocolos es el flujo:

• SAML se centra en la confianza establecida previamente a través del intercambio de metadatos y devuelve datos de identidad directamente en afirmaciones XML firmadas mediante redirecciones del navegador.
• OAuth 2.0 usa códigos de autorización como paso intermedio mientras el cliente intercambia códigos por tokens en un extremo de backend, lo cual permite la entrega segura de tokens sin exponerlos en el navegador.

Use SAML en los siguientes casos:

Requisitos de SSO empresarial

• Gestión centralizada de identidades
• SSO sin fricciones en múltiples aplicaciones empresariales
• Intercambio de atributos de usuario enriquecido (departamento, rol, grupos)

Cumplimiento normativo

• Declaraciones de atributos incorporadas con fines de auditoría y gobernanza
• Uso compartido explícito de datos de identidad con fines de elaboración de informes de cumplimiento

Federación empresarial y gubernamental
SAML se usa mucho para la federación de identidades empresariales y gubernamentales, lo que incluye las plataformas empresariales modernas y los sistemas heredados. Las plataformas de identidades empresariales y gubernamentales suelen ser compatibles tanto con SAML como con OIDC para adaptarse a diferentes requisitos de integración.

Use OAuth 2.0 en los siguientes casos:

Seguridad de API

• Protección de API REST usando ámbitos para un control de acceso granular
• Autorización sin estado para microservicios
• Seguridad de API basada en token

Aplicaciones móviles y nativas

• Formato JSON ligero y código de autorización con la extensión Proof Key for Code Exchange (PKCE)
• Redirecciones seguras basadas en el navegador con navegadores del sistema en lugar de vistas web insertadas

Acceso de terceros

• Delegación de permisos específicos sin compartir credenciales
• Inicio de sesión social (inicio de sesión con Google o Facebook)
• Acceso limitado a los datos del usuario

OIDC es una capa de identidad que tiene como base OAuth 2.0. Presenta tokens de identificación para la autenticación de usuarios y estandariza cómo se representan los atributos de identidad mientras sigue usando OAuth 2.0 para emitir tokens de acceso para la autorización de la API. OIDC no reemplaza a OAuth 2.0, sino que lo amplía para admitir la autenticación y la identidad. En flujos modernos, OIDC gestiona la autenticación (emisión de tokens de identificación), mientras que OAuth 2.0 se encarga de la autorización (emisión de tokens de acceso para llamadas a la API). Ambos suelen funcionar juntos en el mismo flujo.

Artículo destacado	OAuth 2.0	OIDC (extensión de OAuth 2.0)
Respuesta principal	Token de acceso (autorización)	Token de identificación (autenticación)
identidad	No (solo autorización)	Sí (atributos de identidad, perfil de usuario)

1. Interpretar a OAuth 2.0 como un autenticador

• Los tokens de acceso de OAuth 2.0 proporcionan autorización, no identidad
• Use OpenID Connect para la autenticación o implemente alguna verificación adicional

2. Validar inadecuadamente los tokens

• SAML: validar firmas, verificar las condiciones de caducidad (NotBefore/NotOnOrAfter), comprobar público
• OAuth 2.0: validar firmas; caducidad (exp); público (aud); emisor (iss); y, opcionalmente, no antes (nbf)
• El método de validación depende del tipo de token: verifique los JWT a nivel local o use la introspección para tokens opacos

3. Utilizar un flujo inseguro para clientes públicos

• Las aplicaciones nativas no pueden almacenar de forma segura los secretos de los clientes (es decir, son “clientes públicos”)
• Utilice el flujo de código de autorización con PKCE para clientes públicos a fin de evitar la intercepción de códigos de autorización (los flujos sin PKCE, como el flujo Implicit Grant Flow, están obsoletos y deben evitarse en cualquier desarrollo nuevo)

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

SAML se utiliza para la autenticación (determinar la identidad del usuario), mientras que OAuth 2.0 se emplea para la autorización (decidir a qué puede acceder el usuario). SAML se emplea para Enterprise SSO, y OAuth 2.0 se usa para el control de acceso de la API.

¿Puede OAuth 2.0 reemplazar a SAML para el SSO?

OAuth 2.0 por sí solo no puede reemplazar a SAML para el SSO porque es estrictamente un marco de autorización. OIDC (desarrollado con OAuth 2.0 como base) agrega la capa de autenticación necesaria para el SSO; pero, a diferencia de SAML, sus especificaciones de cierre de sesión único son extensiones opcionales que las implementaciones gestionan por separado.

¿Qué protocolo es más seguro?

Ambos protocolos ayudan a brindar garantías sólidas de seguridad cuando se implementan correctamente. Los riesgos aparecen cuando hay defectos de implementación, entre ellos, la ausencia de validación de firmas, un manejo inadecuado de las vidas útiles de los tokens, controles débiles de público y emisor, o una configuración incorrecta de los extremos de autorización. SAML ofrece firmas a nivel de mensaje y cifrado opcional, mientras que OAuth 2.0, combinado con PKCE y la validación adecuada de tokens, proporciona una seguridad equivalente. La selección del protocolo debe priorizar la adecuación a la arquitectura antes que los supuestos de seguridad.

¿Necesito admitir ambos protocolos?

La mayoría de las aplicaciones no necesitan ambos internamente. Sin embargo, puede que necesite admitir ambos al integrarse con proveedores de identidades externos. Los clientes empresariales suelen exigir SAML, mientras que las aplicaciones para consumidores esperan el inicio de sesión social con OAuth 2.0. La plataforma de identidad gestiona la traducción de los protocolos.

¿Por qué se prefiere OAuth 2.0 antes que SAML en las API?

En las API, se prefiere OAuth 2.0 porque los tokens son más pequeños y fáciles de analizar que las afirmaciones XML, la autorización basada en ámbitos se asigna directamente a los permisos de la API, y los lenguajes de programación modernos son más compatibles con las bibliotecas de OAuth 2.0.

Elegir entre SAML y OAuth 2.0 depende de los requisitos de su aplicación y las situaciones de integración. Ambos protocolos garantizan la gestión de identidades y accesos cuando se implementan correctamente.

Emplear una plataforma de identidad como Auth0 elimina la complejidad de los protocolos, ya que es compatible con SAML, OAuth 2.0 y OpenID Connect. La aplicación autentica a los usuarios mediante una API uniforme, más allá del protocolo de fondo. Eche un vistazo a la serie de Introducción a IAM para entender más los protocolos de identidad y las arquitecturas de autenticación moderna.

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í.