SAML 2.0: el estándar que inventó el inicio de sesión único en la web

Una nota en la que se puede confiar

Sara empieza el día abriendo la aplicación de gastos de la empresa, un producto SaaS que corre en servidores de otros. No escribe ninguna contraseña en ella. Su navegador salta un momento a la página de inicio de sesión de la empresa, que ya la conoce de un rato antes, y vuelve con la sesión abierta. La aplicación de gastos nunca vio su contraseña ni le preguntó nada a su directorio. Recibió una nota.

Esa nota es una aserción SAML, y SAML trata de cómo se escribe, se lleva y se comprueba. El artículo de servicios de directorio estableció dónde viven las identidades; este empieza a moverlas. SAML 2.0 es el primer protocolo del stack, el que tomó una identidad guardada en un directorio corporativo y la hizo útil para entrar en aplicaciones que el directorio no controla. Es un estándar de OASIS que se cerró en 2005, y dos décadas después sigue gestionando el inicio de sesión de una parte asombrosa del software empresarial.

El problema que resolvió es uno que siente cualquier empleado. Tienes una identidad corporativa y decenas de aplicaciones, muchas de ellas SaaS. Sin federación, cada una necesita su propia contraseña, lo cual es malo para la seguridad y peor para la paciencia. La respuesta de SAML es dejar que un sistema de confianza te autentique y que cada aplicación crea en la palabra de ese sistema en lugar de tener su propio inicio de sesión. La palabra es un documento XML firmado, la aserción: en la práctica, una nota a prueba de manipulaciones que dice “esta es Sara, se autenticó, estos son sus datos”. La aplicación no comprueba la contraseña de Sara; comprueba la firma y confía en la nota. Todo lo demás es el formato de la nota y cómo se entrega.

Tres roles y la confianza entre ellos

SAML tiene tres actores, y tenerlos claros hace fácil todo lo demás.

El proveedor de identidad (IdP) autentica al usuario y emite aserciones. Lo respalda el directorio: Entra ID, Okta, ADFS, Ping. El IdP es donde se comprueba de verdad la contraseña, o el MFA. El proveedor de servicio (SP) es la aplicación a la que quiere llegar el usuario. Le deja la autenticación al IdP y consume la aserción; la herramienta de gastos de Sara es un SP. Y el principal es el usuario, que vive todo esto como “hago clic en la aplicación y ya estoy dentro”.

La confianza se establece con metadatos

Un SP no puede confiar en cualquier aserción que le llegue. Necesita saber de antemano, y de forma criptográfica, en qué IdP confiar y cómo comprobar sus firmas. Eso se establece con los metadatos SAML, un documento XML que cada parte publica sobre sí misma. Contiene su entityID, su identificador único, normalmente una URL; sus endpoints, adónde enviar y desde dónde recibir los mensajes SAML, como la URL del Assertion Consumer Service del SP; sus certificados de firma, las claves públicas que el otro lado usa para verificar firmas; y los bindings y formatos de NameID que admite.

Configurar una integración SAML es, en el fondo, intercambiar metadatos. El IdP y el SP importan los metadatos del otro, y desde ese momento cada uno conoce la identidad, los endpoints y las claves públicas del otro. Esa confianza, preparada de antemano y anclada en certificados, es la razón por la que un SP puede creer una aserción sin contactar nunca con el directorio del usuario.

sequenceDiagram
  accTitle: Establecer la confianza SAML intercambiando metadatos
  accDescr: Antes de cualquier inicio de sesión, el proveedor de identidad y el proveedor de servicio intercambian metadatos XML. El IdP comparte sus metadatos con su entityID, su endpoint de inicio de sesión y su certificado de firma. El SP comparte los suyos con su entityID, la URL de su Assertion Consumer Service y su certificado. Cada uno importa los metadatos del otro y desde ese momento confían entre sí, así que puede haber inicio de sesión único.
  participant SP as Proveedor de servicio
  participant IdP as Proveedor de identidad
  IdP->>SP: Metadatos del IdP (entityID, URL de SSO, certificado de firma)
  SP->>IdP: Metadatos del SP (entityID, URL de ACS, certificado)
  Note over SP,IdP: Cada uno importa los del otro y ya puede haber SSO

La confianza que se establece una vez no se mantiene sola para siempre. El certificado de firma de los metadatos de un IdP tiene fecha de vencimiento. Cuando vence o se rota y el SP conserva la copia vieja, la comprobación de la firma falla y todos los usuarios se quedan fuera de esa aplicación. Es una de las caídas de SAML más comunes en producción, y la solución es aburrida: automatizar la actualización de los metadatos o, como mínimo, poner la fecha de vencimiento del certificado en un calendario que alguien mire.

Dos formas de empezar: iniciado por el SP o por el IdP

Una sesión de inicio de sesión único puede empezar de dos maneras, y la diferencia importa tanto para la comodidad como para la seguridad.

Iniciado por el SP

El usuario empieza en la aplicación. Es el flujo habitual y recomendado, y es lo que pasó cuando Sara abrió la herramienta de gastos.

sequenceDiagram
  accTitle: Inicio de sesión único SAML iniciado por el SP
  accDescr: El usuario pide una página protegida al proveedor de servicio. El SP crea una solicitud de autenticación y redirige el navegador del usuario al proveedor de identidad. El IdP autentica al usuario con contraseña y MFA, construye una aserción SAML firmada y la envía de vuelta por POST, a través del navegador, al Assertion Consumer Service del SP. El SP comprueba la firma y las condiciones, crea una sesión y concede el acceso.
  actor U as Usuario (navegador)
  participant SP as Proveedor de servicio (app)
  participant IdP as Proveedor de identidad
  U->>SP: Pide una página protegida
  SP->>U: Redirección con AuthnRequest
  U->>IdP: Entrega el AuthnRequest
  IdP->>U: Autenticación (contraseña + MFA)
  IdP->>U: Aserción firmada (HTTP-POST)
  U->>SP: POST de la aserción al ACS
  SP->>SP: Comprueba firma y condiciones
  SP->>U: Sesión creada, acceso concedido

El SP emite un AuthnRequest y redirige el navegador al IdP. El IdP autentica al usuario, construye una aserción firmada y devuelve el navegador a la URL del Assertion Consumer Service (ACS) del SP con la aserción encima. El SP la comprueba y crea su propia sesión. Hay dos cosas que vale la pena notar. La aserción viaja a través del navegador del usuario, porque SAML es un protocolo de canal frontal mediado por el navegador. Y el SP empareja la respuesta con la solicitud que él mismo inició, lo que cierra el paso a familias enteras de ataques de inyección.

Iniciado por el IdP

Aquí el usuario empieza en el IdP, normalmente un portal con los iconos de las aplicaciones, y hace clic en uno. El IdP envía una aserción que nadie pidió directamente al ACS del SP, sin ningún AuthnRequest antes. Es cómodo, la experiencia clásica de portal de aplicaciones, pero más débil. Sin una solicitud con la que emparejarla, una aserción capturada por el camino es más fácil de reutilizar, y el SP tiene menos contexto para comprobarla. La recomendación actual es preferir el flujo iniciado por el SP para todo lo sensible y activar el iniciado por el IdP a propósito, como una comodidad, y no por defecto.

Bindings: cómo viajan los mensajes SAML

Un binding es el transporte, cómo se lleva un mensaje SAML sobre HTTP. SAML 2.0 define tres que vas a encontrar.

El patrón de casi todas las implantaciones es Redirect para la solicitud y POST para la aserción. El AuthnRequest es lo bastante corto para ir en una URL; la aserción, llena de XML firmado, no, así que vuelve como un formulario que se envía solo. Artifact es menos común pero útil cuando no quieres que la aserción pase por el navegador. El navegador lleva un identificador de un solo uso y el SP lo canjea directamente con el IdP, dejando el contenido sensible en un canal de servidor a servidor.

Anatomía de una aserción

La aserción es el corazón de SAML. Es un documento XML con cuatro partes que deberías reconocer de un vistazo.

<saml:Assertion ID="_a1b2c3" IssueInstant="2026-06-10T09:00:00Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <ds:Signature>...</ds:Signature>
 
  <saml:Subject>
    <saml:NameID Format="...emailAddress">sara@example.com</saml:NameID>
    <saml:SubjectConfirmation Method="...bearer">
      <saml:SubjectConfirmationData
        Recipient="https://sp.example.com/acs"
        NotOnOrAfter="2026-06-10T09:05:00Z"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
 
  <saml:Conditions NotBefore="2026-06-10T08:59:00Z"
                   NotOnOrAfter="2026-06-10T09:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
 
  <saml:AuthnStatement AuthnInstant="2026-06-10T09:00:00Z"
                       SessionIndex="_sess789">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>...PasswordProtectedTransport</saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
 
  <saml:AttributeStatement>
    <saml:Attribute Name="department">
      <saml:AttributeValue>Engineering</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Cada bloque responde a una pregunta distinta. El Subject dice de quién trata la aserción: el NameID es el identificador, aquí una dirección de correo, y SubjectConfirmation dice cómo puede confirmar el SP que quien la presenta es el sujeto, con un Recipient y un NotOnOrAfter que la atan a este SP y a este momento. Las Conditions dicen cuándo y para quién es válida: NotBefore y NotOnOrAfter fijan una ventana corta, normalmente de minutos, y AudienceRestriction nombra el SP exacto al que va dirigida, así que cualquier otro SP debe rechazarla. El AuthnStatement dice cómo se autenticó el usuario: AuthnInstant es cuándo, AuthnContextClassRef describe el método, como una contraseña sobre TLS o un contexto de MFA, y SessionIndex la vincula a la sesión del IdP, algo que importa después para el cierre de sesión. Y el AttributeStatement dice qué más debe saber el SP: área, grupos, roles, tomados del directorio y usados por el SP para decidir qué puede hacer el usuario.

Hay un detalle de estructura que conviene entender bien. La aserción suele viajar dentro de un sobre <samlp:Response>, y se puede firmar la respuesta, la aserción o las dos. Suena a detalle de puristas, pero es donde se gana o se pierde la seguridad de SAML. Un SP que comprueba solo la firma de la respuesta mientras lee los atributos de la aserción deja justo el hueco que aprovechan los ataques de XML Signature Wrapping. La regla que lo evita es fácil de decir y fácil de hacer mal: verifica la firma del elemento que de verdad usas, y asegúrate de que ese elemento firmado es aquel en cuyo contenido confías.

La seguridad de un SP depende por completo de comprobar la aserción, no solo de leerla. Como mínimo tiene que verificar la firma XML contra el certificado conocido del IdP, comprobar NotBefore y NotOnOrAfter con muy poca tolerancia de reloj, confirmar que la audiencia es él mismo y confirmar que el destinatario coincide con su URL de ACS. Un SP que lee los atributos antes de verificar la firma es la vulnerabilidad crítica clásica: se va a creer una nota falsificada.

Firma y cifrado

El modelo de confianza de SAML es criptográfico y se divide en dos preocupaciones distintas.

XML Signature aporta integridad y autenticidad. El IdP firma la aserción, o la respuesta entera, con su clave privada, y el SP la comprueba con el certificado público del IdP que figura en los metadatos. Una firma válida demuestra que la aserción viene de verdad del IdP de confianza y que no cambió ni un byte por el camino. En cualquier implantación sensata es obligatoria; una aserción sin firmar es una nota que pudo escribir cualquiera.

XML Encryption aporta confidencialidad. El IdP puede cifrar la aserción, o atributos concretos, con la clave pública del SP, para que solo el SP pueda leerla. Importa porque la aserción pasa por el navegador del usuario, donde se puede inspeccionar. Si lleva atributos sensibles, un documento nacional, una banda salarial, un rol clínico, el cifrado los mantiene privados. El cifrado es opcional y se usa de forma selectiva. La firma responde si puedes confiar en la nota; el cifrado, quién más puede leerla.

Dónde fallan las implementaciones de SAML

La dependencia de SAML de un XML complejo ha producido una familia reconocible de ataques, recogidos en la SAML Security Cheat Sheet de OWASP. XML Signature Wrapping reorganiza el XML para que el SP compruebe una firma legítima pero lea contenido que controla el atacante; la defensa es confirmar que la firma cubre de verdad el elemento que usas. No comprobar la firma, o comprobarla a medias, aceptando aserciones sin verificar o verificando la respuesta pero no la aserción, es el error de implementación de SAML más común. Confundir la audiencia o el destinatario, sin confirmar que la aserción se emitió para tu SP, permite reutilizar en una aplicación una aserción pensada para otra. Y la reutilización, volver a usar una aserción capturada dentro de su ventana de validez, se limita con vidas cortas y recordando los identificadores de aserción ya usados.

El hilo común es que SAML es tan seguro como las comprobaciones del SP. El protocolo es sólido; la mayoría de los fallos reales son SP que comprueban demasiado poco.

Cierre de sesión único: la mitad difícil

SAML define también el cierre de sesión único (SLO), terminar con una sola acción las sesiones de un usuario en todos los SP federados. El SessionIndex del AuthnStatement lo hace posible en principio: vincula cada sesión de un SP con la sesión del IdP, así que cuando el usuario cierra sesión el IdP puede enviar un LogoutRequest a cada SP que tenga una sesión con ese índice.

En la práctica, el SLO es famoso por lo poco confiable. Cada SP tiene que implementar bien los endpoints de cierre de sesión, estar accesible en ese momento y atender la solicitud, y un solo SP que se porte mal o esté caído rompe la cadena y deja vivas sesiones que el usuario cree cerradas. Muchas organizaciones tratan el SLO como un intento de buena fe y confían, en cambio, en sesiones cortas y en la revocación en el IdP. La lección va mucho más allá de SAML y vuelve en el artículo de OIDC: federar el inicio de sesión es mucho más fácil que federar el cierre. Empezar la confianza en muchos lugares a la vez es simple; terminarla en todas partes en el mismo momento, entre sistemas independientes, es difícil de verdad.

Configurar una integración en la práctica

¿Qué implica de verdad montar una conexión SAML? Los profesionales siguen más o menos los mismos pasos.

Intercambian metadatos, importando los del IdP en el SP y los del SP en el IdP, o cargando a mano el entityID, la URL de ACS y los certificados cuando no hay una URL de metadatos. Eligen el formato de NameID, decidiendo qué identifica al usuario de forma única y estable entre sistemas, una dirección de correo o un identificador persistente y opaco; un NameID que no coincide es la causa número uno de “autentica, pero la aplicación no reconoce al usuario”. Mapean atributos, decidiendo qué atributos del directorio entrega el IdP y con qué nombres exactos los espera el SP, que es donde se va de verdad casi todo el tiempo de una integración. Definen la firma y el cifrado y confirman que los dos lados están de acuerdo en los algoritmos. Y prueban los bordes: el primer inicio de sesión, volver a entrar, la diferencia de reloj entre servidores y, sobre todo, la rotación de certificados.

La sabiduría de campo es directa. Casi todas las quejas de que “SAML es inestable” vienen de errores de mapeo de atributos o de certificados vencidos, no del protocolo. Guarda las URLs de metadatos y las fechas de vencimiento de los certificados en algún lugar vigilado, prefiere aserciones firmadas con audiencias estrictas y vidas cortas, y comprueba con rigor del lado del SP. Si haces eso, SAML es aburridamente confiable; si no, vas a perseguir bloqueos misteriosos cada vez que se renueve un certificado.

Cuándo SAML sigue siendo la opción correcta

Los dos próximos artículos tratan OAuth 2.0 y OIDC, más livianos, basados en JSON y mejor adaptados a apps móviles y APIs. Eso no convierte a SAML en algo heredado. Lo convierte en algo especializado, y en su especialidad muchas veces sigue siendo la mejor herramienta.

Para que los empleados entren en aplicaciones de negocio, casi todos los productos SaaS empresariales admiten SAML y todos los IdP corporativos lo hablan con soltura, así que es el camino de menor resistencia. En la federación B2B, cuando los empleados de una empresa necesitan entrar en los sistemas de otra, la confianza de SAML basada en metadatos y anclada en certificados entre dos empresas está madura y se entiende bien. Y en sectores regulados con mucha exigencia de auditoría, SAML suele estar muy arraigado, con controles ya establecidos y auditores que lo conocen; cambiar de protocolo trae un riesgo que la regulación no premia.

SAML es la herramienta equivocada para el inicio de sesión de consumidores a gran escala, las apps móviles nativas y la autorización entre APIs, donde el XML y las redirecciones del navegador resultan torpes. Ese es justamente el terreno de OAuth 2.0 y OIDC.

Las organizaciones grandes suelen usar los dos: SAML para lo que ya está implantado y OIDC para lo nuevo. Un profesional de IAM necesita entender el compromiso entre ambos en lugar de ser fiel a un protocolo. Una regla práctica: si el usuario es un empleado que entra en una aplicación web de negocio o B2B, SAML es una buena opción, u OIDC si la aplicación lo admite igual de bien. Si el usuario es un consumidor, el cliente es una app móvil o de una sola página, o estás autorizando el acceso a una API, ve a OAuth 2.0 y OIDC.

Resumen

SAML 2.0 es inicio de sesión único federado en la web mediante aserciones XML firmadas.

1. Hay tres roles: el IdP autentica y emite aserciones, el SP las consume y el usuario vive un inicio de sesión sin fricciones. La confianza se establece de antemano intercambiando metadatos con entityIDs, endpoints y certificados, y hay que mantenerla a medida que vencen los certificados.
2. Hay dos flujos: iniciado por el SP, que empieza en la aplicación y es el recomendado, e iniciado por el IdP, que empieza en un portal, cómodo pero más débil.
3. Hay tres bindings: Redirect para la solicitud, POST para la aserción y Artifact para un canal trasero en escenarios de alta seguridad.
4. La aserción lleva un Subject, unas Conditions, un AuthnStatement y un AttributeStatement, y la seguridad del SP depende por completo de comprobarlo todo, sobre el elemento que de verdad usa.
5. La firma da integridad y autenticidad y es obligatoria; el cifrado da confidencialidad y es opcional. La mayoría de las brechas de SAML son fallos de comprobación, no del protocolo.
6. El cierre de sesión único es poco confiable en la práctica, así que el trabajo de verdad lo hacen las sesiones cortas y la revocación en el IdP.
7. SAML sigue encajando en el inicio de sesión de la plantilla, la federación B2B y los entornos con mucho cumplimiento; OAuth y OIDC encajan en consumidores, móvil y APIs.

Ejercicios prácticos

Están pensados para hacerlos, no solo para leerlos.

1. Decodifica una aserción real. Instala una extensión de rastreo de SAML en el navegador, entra en alguna aplicación protegida con SAML que uses y captura el flujo. Busca el AuthnRequest y la aserción, decodifica la aserción de base64 y señala su Subject, sus Conditions, su AuthnStatement y su AttributeStatement en el XML real.
2. Identifica los bindings. En esa misma captura, confirma qué binding llevó el AuthnRequest y cuál la aserción, y comprueba que siga el patrón de Redirect y después POST. Mira NotOnOrAfter para ver lo corta que es de verdad la vida de la aserción.
3. Monta una federación. Usa un entorno de pruebas público como samltest.id para jugar los dos papeles: registra un SP de prueba, sube los metadatos y corre un inicio de sesión iniciado por el SP de principio a fin. Después rómpelo a propósito, cambia la audiencia o haz que no coincida un certificado, y mira cómo el SP rechaza la aserción.
4. Audita una configuración. Heredas un SP que solo comprueba la firma de la respuesta externa, acepta aserciones válidas durante 24 horas y no tiene AudienceRestriction. Enumera cada problema y el cambio exacto para cada uno.
5. Diseña la incorporación de un socio. Un socio necesita que sus empleados entren en tu aplicación a través de su propio IdP. Dibuja el intercambio de metadatos, el formato de NameID que elegirías y por qué, los tres atributos que mapearías y cómo gestionarías la rotación de sus certificados.
6. Elige el protocolo. Toma una aplicación a la que entres con SAML y comprueba si también ofrece OIDC. Decide cuál usarías para una aplicación web interna nueva y cuál para la integración de un socio B2B, y justifica cada decisión en dos frases.

Tres preguntas para ponerte a prueba

1. Un SP acepta una aserción SAML y lee los grupos del usuario para darle acceso de administrador, pero solo comprueba la firma de la respuesta externa, no la de la aserción. ¿Qué tipo de ataque invita eso, y qué debería comprobar exactamente el SP?
2. Un colega activa el inicio de sesión iniciado por el IdP en una aplicación de finanzas porque el portal de aplicaciones es cómodo. ¿Cuál es la objeción de seguridad y qué recomendarías?
3. Explica por qué SAML usa HTTP-Redirect para el AuthnRequest pero HTTP-POST para la aserción, y qué cambia HTTP-Artifact sobre por dónde viaja la aserción.