Security Assertion Markup Language (SAML) 2.0 es un protocolo basado en XML que permite la federación de identidades entre dominios de seguridad independientes para ofrecer inicio de sesión único (SSO). SAML permite a los usuarios autenticarse con un proveedor de identidad (IdP) una sola vez y luego acceder a múltiples proveedores de servicios (SP) sin necesidad de volver a ingresar sus credenciales.

SAML 2.0 fue ratificado como un estándar abierto de OASIS en 2005. Se sigue usando mucho para la federación de identidades empresariales y gubernamentales, aunque OpenID Connect (OIDC) es cada vez más común en aplicaciones modernas.

Ejemplo: Al iniciar sesión en el centro interno de su empresa, SAML le permite acceder inmediatamente a los repositorios de GitHub Enterprise, las solicitudes de Jira y la documentación de Confluence durante todo el día sin tener que ingresar sus credenciales nuevamente en cada herramienta. El portal actúa como un lanzador de aplicaciones alojado en un SP o un IdP, y las herramientas posteriores (Jira, GitHub Enterprise) son SP adicionales que confían en el mismo IdP.

SAML admite dos patrones de inicio, y ambos tienen como resultado el SSO.

Flujo iniciado por el SP (estándar para SaaS B2B)

Cuando un usuario intenta acceder a la aplicación directamente:

1. El usuario intenta acceder a la aplicación (SP).
2. La aplicación redirige al usuario a la página de inicio de sesión del IdP.
3. El usuario se autentica con el IdP.
4. El IdP genera una afirmación SAML firmada.
5. El IdP redirige al usuario de vuelta a la aplicación con la afirmación.
6. La aplicación valida la firma de la afirmación y crea una sesión.
7. El usuario accede a la aplicación.

Flujo iniciado por el IdP (común en entornos empresariales)

Cuando un usuario empieza desde el panel corporativo:

1. El usuario inicia sesión en el portal corporativo (IdP).
2. El usuario hace clic en la aplicación dentro del panel.
3. El IdP genera una afirmación SAML firmada.
4. El IdP redirige automáticamente al usuario a la aplicación (SP) con la afirmación.
5. La aplicación valida la afirmación y crea una sesión.
6. El usuario accede a la aplicación.

Ambos flujos verifican la identidad sin necesidad de compartir contraseñas entre sistemas. El IdP puede exigir autenticación multifactor (MFA) antes de emitir la afirmación, lo que agrega una capa de seguridad.

En el caso del SSO iniciado por el IdP, no se incluye un valor InResponseTo del SP. Los SP usan más las marcas de tiempo de las afirmaciones (NotBefore/NotOnOrAfter) y la protección contra la repetición al validar las afirmaciones iniciadas por el IdP.

SAML permite la federación de identidades mediante tres componentes principales:

• El IdP, un sistema que autentica a los usuarios y almacena las credenciales.
• El SP, una aplicación que depende del IdP para autenticar y conceder acceso.
• La afirmación SAML, un documento XML firmado digitalmente que contiene datos de identidad verificados y se transfiere del IdP al SP.

Esta afirmación confirma la identidad del usuario y el acceso que tiene autorizado, lo que permite al SP conceder o denegar el acceso sin tener que gestionar directamente las credenciales del usuario.

Una afirmación SAML es un documento XML estructurado con tres tipos de declaraciones:

• Declaraciones de autenticación, que confirman que el usuario está autenticado y registran la hora en que ocurrió el evento.
• Declaraciones de atributos, que contienen datos e información del usuario (correo electrónico, nombre, grupos, roles). La mayoría de las implementaciones transmiten datos de autorización (como roles o grupos) mediante declaraciones de atributos. En las implementaciones de SAML para la fuerza laboral, las declaraciones de atributos suelen incluir datos relacionados con la autorización, como grupos o roles.
• Declaraciones de decisiones de autorización, que se definen en la especificación de SAML, pero rara vez se usan en las implementaciones de SSO actuales.

La afirmación incluye los siguientes datos:

• El emisor o IdP que la creó.
• El sujeto o usuario.
• Las condiciones, es decir, el período de validez (por ejemplo, NotBefore y NotOnOrAfter) y el público objetivo.
• La firma o prueba criptográfica de autenticidad. El SP debe verificar que el elemento que se está procesando sea el mismo al que hace referencia el ID de la firma para evitar ataques de encapsulamiento de firmas XML.

La afirmación puede estar cifrada (normalmente, el elemento <Assertion> en lugar de todo el elemento <Response>, aunque también se pueden cifrar atributos individuales para datos confidenciales). El SP debe poder descifrar los elementos cifrados si es necesario.

Los desarrolladores suelen confundir SAML con OAuth 2.0 y OIDC. Esta es una comparación entre ellos:

Aspecto	SAML 2.0	OAuth 2.0	OpenID Connect
Uso principal	Autenticación de SSO empresarial	Autorización delegada	Autenticación moderna
Formato	XML (análisis complejo, riesgo de ataques de encapsulamiento de firma XML)	La especificación no tiene en cuenta el formato del token, aunque muchas implementaciones usan tokens de acceso JWT	Con base en JSON (token de ID JWT)
Tipo de token	Afirmación de SAML	Token de acceso	Token de ID y token de acceso
Transporte	Las solicitudes de autenticación suelen usar HTTP-Redirect; las afirmaciones casi siempre se envían mediante HTTP-POST	Normalmente, a través del encabezado de autorización HTTP (tokens portadores), aunque existen otros transportes (form_post/query) según el flujo	Encabezado de autorización HTTP
Compatibilidad con dispositivos móviles	Poca compatibilidad con aplicaciones nativas (suele requerir WebView o una aplicación intermediaria)	Excelente	Excelente
Público objetivo	Empresas, Gobiernos	Aplicaciones para consumidores, API	Aplicaciones para consumidores, empresas modernas
Caso de uso	SSO empresarial, autenticación de la fuerza laboral	Delegación de acceso a la API, integraciones de terceros	Aplicaciones modernas, autenticación móvil, SSO para consumidores

OAuth 2.0 se encarga de la autorización (lo que el usuario puede hacer), y no de la autenticación (quién es el usuario). OAuth 2.0 por sí solo no es un protocolo de autenticación. Los proveedores suelen usar métodos propios para agregar información de identidad; sin embargo, estos métodos no están estandarizados. OpenID Connect es el estándar para agregar autenticación a OAuth 2.0.

SAML maneja la autenticación y puede incluir atributos de autorización, pero no es un marco de autorización. Las decisiones de autorización se toman en la aplicación una vez que finaliza la autenticación de SAML.

Los protocolos no se excluyen mutuamente. Muchas plataformas de identidad admiten las tres opciones, lo que permite elegir en función de las necesidades de los usuarios.

Validación de firma XML

SAML se basa en firmas XML para garantizar la seguridad. Implementar la validación correctamente requiere varios pasos:

• Validar el algoritmo de la firma (rechazar algoritmos débiles, como SHA-1).
• Verificar la cadena de certificados de firma.
• Verificar el estado de caducidad y revocación del certificado.
• Asegurarse de que el elemento firmado coincida con el contenido analizado.
• Los SP deben validar al menos una firma de confianza (ya sea en <Response> o en <Assertion>, según la configuración) y asegurarse de que solo se procese el elemento esperado.
• Los SP deben cerciorarse de que la firma cubra la referencia correcta para evitar el encapsulamiento XML. Es posible que algunas bibliotecas no exijan la cobertura de referencias. Verifique que la firma haga referencia al ID de elemento correcto.

Un solo error en la validación de firmas crea vulnerabilidades de seguridad. Los atacantes pueden aprovechar el encapsulamiento de firmas XML para eludir la autenticación.

Considere la posibilidad de usar una biblioteca SAML probada en lugar de crear una desde cero.

Desviación del reloj y validación de la marca de tiempo

Las afirmaciones SAML incluyen las condiciones (NotBefore) y (NotOnOrAfter). Las diferencias horarias entre el IdP y el SP pueden causar el rechazo de afirmaciones válidas.

Prácticas recomendadas:

• Permita una tolerancia de desviación del reloj de 2 a 5 minutos.
• Implemente la configuración NTP adecuada en sus servidores.
• Registre los errores de validación de la marca de tiempo por separado para la depuración.

Intercambio de metadatos

Normalmente, SAML usa el intercambio de metadatos entre el IdP y el SP, aunque no es un requisito estricto de la especificación.

• Los metadatos del IdP contienen certificados de firma, extremos e ID de entidad.
• Los metadatos del SP describen las URL y los requisitos de Assertion Consumer Service (ACS) de la aplicación.

Los cambios en los metadatos provocan errores de SSO. Cuando los IdP rotan los certificados, debe actualizar la configuración. Algunas empresas requieren aprobación manual para los cambios en los metadatos del SP, lo que puede retrasar las implementaciones.

Almacene los metadatos del IdP en su base de datos, no en los archivos de configuración. No todos los IdP admiten URL de metadatos dinámicas. Cuando esté disponible, la actualización automática es la práctica recomendada.

Incoherencias en la asignación de atributos

Cada IdP diferente envía nombres de atributos distintos. La aplicación necesita una asignación de atributos flexible para gestionar estas variaciones. Permita que los clientes configuren qué atributos de SAML se corresponden con los campos de usuario de su aplicación.

Al usar el control de acceso basado en roles (RBAC), los IdP pueden enviar información de roles en los atributos de SAML. La aplicación debe asignar estos roles del IdP al sistema interno de permisos.

Valide siempre la firma

Cada afirmación SAML se debe validar criptográficamente para confirmar lo siguiente:

1. Que la firma existe.
2. Que la firma es válida para el contenido de la afirmación.
3. Que las cadenas del certificado de firma están vinculadas a una raíz de confianza.
4. Que el elemento firmado coincide con el contenido analizado. Los SP deben cerciorarse de que la firma cubra la referencia correcta para evitar el encapsulamiento XML.

Nunca omita la validación de la firma, ni siquiera durante el desarrollo. Es la base de la seguridad de SAML.

Valide todas las condiciones de la afirmación

Más allá de las firmas, valide lo siguiente:

• Emisor. El emisor debe coincidir con el IdP configurado.
• Público. El público debe contener el ID de entidad de la aplicación.
• NotBefore/NotOnOrAfter. La hora actual debe estar dentro del intervalo válido.
• Destinatario. El destinatario debe coincidir con la URL de Assertion Consumer Service (si está presente).
• InResponseTo. Debe coincidir con el ID de su solicitud de autenticación (para flujos iniciados por el SP).

Prevenga ataques de repetición y encapsulamiento de firma

La especificación SAML no exige usar las afirmaciones una sola vez, por lo que la protección contra ataques de repetición es responsabilidad del SP.

1. Almacene el ID de la afirmación (no el ID de la respuesta), usado como un valor de una sola vez o nonce para evitar la repetición, en una memoria caché con un TTL que coincida con el período de validez de la afirmación.
   Práctica recomendada: Configure el TTL de la memoria caché al menos en el período NotOnOrAfter de la afirmación, idealmente con un poco de búfer (algunos segundos) para tener en cuenta la latencia de la red.
2. Rechace cualquier afirmación con un ID que haya visto antes.
3. Borre periódicamente los ID caducados para gestionar el tamaño de la memoria caché.

Como primera medida de protección, el SP debe validar las marcas de tiempo NotBefore y NotOnOrAfter. El almacenamiento en caché de los ID de las afirmaciones es secundario.

Use HTTPS en todas partes

Las afirmaciones de SAML solo deben transmitirse por HTTPS. Aunque estén firmadas, transmitirlas por HTTP expone a los usuarios a ataques de intermediario (man-in-the-middle).

Configure la URL de Assertion Consumer Service (ACS) con HTTPS únicamente. La mayoría de los IdP bloquearán los extremos HTTP o lanzarán una advertencia.

Implemente el cierre de sesión correctamente

SAML es compatible con el cierre de sesión único (SLO), lo que permite a los usuarios cerrar sesión en todas las aplicaciones conectadas de forma simultánea. Su implementación es opcional, pero se recomienda para aplicaciones que deban prestar especial atención a la seguridad.

El SLO puede ser de canal frontal (redirecciones del navegador) o de canal posterior (de servidor a servidor). Si bien el SLO de canal frontal se admite ampliamente, es frágil. Existe el SLO de canal posterior, pero es complejo y rara vez se implementa. La interoperabilidad varía, ya que los distintos IdP y SP implementan el SLO de manera diferente, por lo que conviene probar con varios proveedores.

Crear una implementación de SAML segura desde cero requiere un profundo conocimiento de la seguridad XML y, por lo general, solo se recomienda para implementaciones de IdP o casos de uso altamente especializados.

Estas son las opciones:

Plataformas de identidad

Algunas plataformas de identidad ayudan a gestionar la complejidad de SAML con lo siguiente:

• Implementaciones prediseñadas para IdP y SP de SAML
• Gestión de metadatos automática
• Gestión de rotación de certificados
• Compatibilidad con varios IdP por aplicación
• Registros de auditoría detallados

Este enfoque ofrece compatibilidad con SAML para clientes empresariales y, a la vez, usa protocolos modernos (OIDC, OAuth 2.0) para aplicaciones orientadas al consumidor. Algunas plataformas traducen entre un protocolo y otro sin problemas.

Bibliotecas SAML

Para los equipos que necesitan mayor control, las bibliotecas SAML de mayor trayectoria se encargan del análisis XML, la validación de firmas y los detalles de protocolo de bajo nivel.

• Node.js: passport-saml, samlify
• Python: python3-saml, pysaml2
• Java: Spring Security SAML, OpenSAML
• .NET: Sustainsys.Saml2, ITfoxtec.Identity.Saml2
• Ruby: ruby-saml
• PHP: SimpleSAMLphp

Incluso las bibliotecas SAML de mayor trayectoria no gestionan automáticamente los ataques de repetición ni las afirmaciones cifradas. Los desarrolladores deben implementar el almacenamiento en caché/nonces y el descifrado según sea necesario, y cerciorarse de que se verifique la referencia de la firma.

Elija SAML en los siguientes casos:

• Clientes empresariales con una infraestructura SAML implementada.
• Creación de una aplicación SaaS B2B que requiera SSO empresarial.
• Integración con sistemas gubernamentales.
• Respuestas a RFP que requieran compatibilidad con SAML.

Elija OIDC u OAuth 2.0 en los siguientes casos:

• Creación de aplicaciones para consumidores.
• Necesidad de autenticación de la aplicación móvil.
• Implementación de autorización de la API.
• Preferencia por protocolos más sencillos basados en JSON.
• Infraestructura desde cero sin requisitos heredados.

Muchas aplicaciones admiten varios protocolos. El IdP que elija debe ser compatible con SAML para clientes empresariales y con OIDC para el resto de los usuarios. Considere usar métodos de autenticación sin contraseña, como WebAuthn y claves de acceso, para mejorar la experiencia del usuario.

Antes de publicar la compatibilidad con SAML, realice pruebas exhaustivas.

Pruebe varios IdP

Cada IdP implementa SAML de forma ligeramente distinta. No dé por sentado que todos los IdP se comportarán igual. Los nombres de los atributos, los formatos de metadatos y el manejo de certificados varían.

Pruebe casos extremos

• Desviación del reloj (ajuste la hora del servidor en ±5 minutos).
• Rotación de certificados (actualice los certificados del IdP y compruebe que no haya tiempo de inactividad).
• Firmas no válidas (altere las afirmaciones y confirme el rechazo).
• Afirmaciones caducadas (use afirmaciones de prueba antiguas).
• Ataques de repetición (reenvíe afirmaciones válidas y confirme el rechazo).

Supervise errores de validación

Registre todos los errores de validación de SAML con el ID de la afirmación, el motivo, la entidad del IdP y la marca de tiempo para la depuración. Estos registros son esenciales para solucionar los problemas de los clientes. Los errores de SAML suelen deberse a problemas de configuración más que a errores de código.

¿Qué problema resuelve SAML?

SAML proporciona SSO al habilitar la federación de identidades para usuarios empresariales. Su principal beneficio es que simplifica la seguridad de las aplicaciones al transferir la responsabilidad del almacenamiento y la gestión de las contraseñas de los usuarios a un IdP dedicado. Esto reduce la superficie de ataque de la aplicación, disminuye las llamadas a la mesa de ayuda para restablecer contraseñas y centraliza la aplicación de las políticas.

¿Qué es SAML? ¿Un protocolo de autenticación o uno de autorización?

SAML es principalmente un protocolo de autenticación y federación, y está diseñado para verificar la identidad del usuario. No es, por sí solo, un marco de autorización, como OAuth 2.0. SAML responde a la pregunta “¿quién es este usuario?” transmitiendo una afirmación firmada (una declaración de identidad) desde un IdP a un SP. La autorización (que determina lo que el usuario puede hacer) se produce después de que se completa la autenticación SAML, normalmente, mediante los atributos del usuario (por ejemplo, rol o departamento) que se encuentran en la afirmación SAML.

¿En qué se diferencia SAML de OAuth 2.0 y OpenID Connect?

SAML es un estándar antiguo basado en XML y está diseñado para la federación de identidades empresariales y el SSO de los empleados. OAuth 2.0 es un marco de autorización que emite tokens de acceso para conceder acceso delegado y de ámbito limitado a las API. OIDC es una capa de identidad basada en OAuth 2.0 que agrega autenticación estandarizada mediante tokens de ID (JWT), optimizada para aplicaciones web, móviles y basadas en API. Los tres permiten el acceso, pero SAML se centra en el SSO empresarial, mientras que OAuth y OIDC son más adecuados para los casos actuales de autenticación de aplicaciones y autorización de API.

¿Se sigue usando SAML?

Sí. SAML sigue siendo el protocolo principal para el SSO empresarial, especialmente en grandes organizaciones y agencias gubernamentales con infraestructuras de identidad ya implementadas. Si bien OIDC va ganando terreno en el ámbito de las aplicaciones, la amplia adopción empresarial de SAML significa que se sigue usando y admitiendo activamente.

¿Es SAML un estándar seguro? ¿Cuáles son los riesgos?

SAML es seguro cuando se implementa correctamente. El protocolo usa firmas digitales XML y cifrado para proteger los datos de identidad. Los riesgos pueden derivar de una validación inadecuada de las afirmaciones. Los SP deben verificar las firmas XML, validar las condiciones de las afirmaciones (incluidos el emisor, el público y las marcas de tiempo) e implementar la protección contra la repetición.

Auth0 ayuda a los desarrolladores a implementar SAML de forma rápida y segura, lo que permite habilitar el SSO empresarial sin necesidad de diseñar ni mantener una infraestructura SAML desde cero.

Explore nuestra serie de Introducción a la IAM sobre 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í.