El SSO: SAML y OpenID Connect explicados de forma sencilla
Una sola cuenta abre varias aplicaciones gracias a un token. Qué hacen SAML y OpenID Connect, y cómo actuar ante las trampas.
En 30 segundos
- Dónde ocurre
- Cada vez que se abre una aplicación de la empresa que redirige a la página de inicio de sesión común.
- Qué quiere el atacante
- Un token, una cookie de sesión o una autorización concedida a una aplicación trampa, que le abren el acceso sin conocer la contraseña23.
- El reflejo
- Comprobar la dirección de la página de inicio de sesión, activar la doble autenticación en la cuenta principal, cerrar sesión en un equipo compartido y avisar de cualquier solicitud de inicio de sesión inesperada.
- Si ya ha ocurrido
- Avisar sin demora al departamento de informática, indicando la página que estaba abierta y la autorización concedida.
De qué se trata
El SSO (single sign-on, inicio de sesión único) permite autenticarse una sola vez ante un proveedor de identidad y obtener después acceso a varias aplicaciones sin crear ni recordar una contraseña para cada una1. El empleado introduce sus credenciales en la página de inicio de sesión de la empresa, y las aplicaciones reciben una prueba de su identidad en lugar de su contraseña.
Dos protocolos sirven sobre todo para este intercambio: SAML y OpenID Connect (OIDC). No se ven en pantalla, pero sus tokens se han convertido en un objetivo: robar el token o la sesión equivale a robar el acceso.
Preguntas directas
¿Qué es el SSO?
Una cuenta única, gestionada por un proveedor de identidad, sirve para varias aplicaciones. El documento del NIST sobre la federación de identidad describe este caso: el usuario no se autentica directamente ante la aplicación, sino que el proveedor de identidad produce una aserción, a menudo a petición de la aplicación1. El NIST precisa que este mecanismo evita tener credenciales distintas para cada servicio1.
¿Qué diferencia hay entre SAML y OpenID Connect?
SAML 2.0 es un protocolo que permite a las aplicaciones ofrecer SSO a sus usuarios; intercambia aserciones entre el proveedor de identidad y la aplicación4. OpenID Connect amplía el protocolo de autorización OAuth 2.0 para convertirlo en un protocolo de autenticación, y el SSO pasa por un token de seguridad llamado token de identidad (ID token)5. El NIST cita ambos como ejemplos de protocolos de federación, con una aserción que adopta la forma de un token de identidad OIDC o de una aserción SAML1.
¿Es el SSO menos seguro que una contraseña por aplicación?
Desplaza el riesgo más que suprimirlo. El empleado ya no tiene que gestionar una contraseña para cada aplicación1, pero una cuenta única abre varios servicios: si un atacante toma el control de ella, todos los que la aceptan quedan expuestos. Las trampas que se describen más abajo detallan este punto.
¿Qué protege la doble autenticación y qué no protege?
Protege el inicio de sesión inicial. No protege contra un token o una cookie ya robados: el acceso directo mediante token anula el efecto de un segundo factor6, y las cookies de sesión pueden eludir algunos protocolos de autenticación multifactor3.
1Cómo funciona2 min
Dos actores intercambian información: el proveedor de identidad, que autentica a la persona, y la aplicación, que confía en lo que él afirma4. El NIST llama a la aplicación «parte confiante» (relying party) y llama aserción al mensaje del proveedor de identidad que la informa sobre la persona1.
Con SAML, Microsoft explica que la aplicación registra ante el proveedor de identidad una dirección de redirección y una dirección de metadatos, que permiten obtener la clave de firma4. Con OIDC, la aplicación obtiene además un documento de configuración público que proporciona las direcciones necesarias y las claves públicas con las que se verifica la firma de los tokens5. OWASP describe para SAML una respuesta que contiene la aserción firmada digitalmente con la clave privada del proveedor de identidad7.
Un token no es una contraseña: certifica una autenticación ya realizada. Para SAML, MITRE indica una duración de vida por defecto de una hora, modificable en el token8.
En la versión 2017/2020 de sus directrices, hoy sustituida, el NIST clasifica las aserciones en tres niveles. En el primero, la aserción está firmada por el proveedor de identidad. En el segundo, además está cifrada para la aplicación. En el tercero, el usuario demuestra además que posee una clave vinculada a la aserción1. La versión SP 800-63C-4, fechada en julio de 2025, sustituye a la del 2 de marzo de 20209; por tanto, estos tres niveles no son la norma actual1.
2Qué hace usted1 min
- Mire la dirección de la página de inicio de sesión antes de escribir una contraseña. Hay atacantes que capturan la sesión por el camino, por ejemplo con las herramientas evilginx2 y Muraena, utilizadas en campañas de phishing3.
- Active la doble autenticación en su cuenta principal, la que abre las demás aplicaciones. Comprometer el acceso al correo principal puede permitir llegar a los demás servicios mediante el procedimiento de contraseña olvidada6.
- Cierre sesión en un equipo compartido. Las cookies de sesión suelen seguir siendo válidas mucho tiempo, incluso cuando ya no se usa la aplicación3. En Microsoft, cerrar sesión pone fin a la sesión del usuario5.
- Lea la ventana de solicitud de autorización antes de hacer clic. Pide al usuario que conceda permisos a una aplicación5.
- Avise de cualquier solicitud de inicio de sesión o de autorización que usted no haya provocado, sobre todo después de un mensaje que le empuje a hacer clic en un enlace: así consigue un atacante que se conceda acceso a su aplicación2.
3Las trampas2 min
Los falsos portales de inicio de sesión
Los marcos de código abierto evilginx2 y Muraena recogen cookies de sesión mediante un proxy malicioso colocado entre la víctima y el sitio real3. Kali365 obtuvo tokens de acceso y de actualización de OAuth empujando a las víctimas a validar una solicitud de autorización de dispositivo iniciada por el atacante, e interceptando las sesiones mediante una infraestructura de proxy inverso2.
El robo de token o de sesión
Los tokens de acceso sirven para hacer solicitudes autorizadas en nombre de un usuario6. Una vez robados, sustituyen a la contraseña: el grupo APT29 utiliza tokens robados para acceder a cuentas sin contraseña2. Estos accesos por API son difíciles de detectar, incluso para el proveedor, porque se parecen a un uso normal6. Cambiar la contraseña tampoco basta necesariamente para cortarlos6. Los tokens de actualización permiten obtener otros nuevos sin consultar al usuario2.
Los consentimientos OAuth abusivos
Un atacante registra su propia aplicación en el servidor de autorización y luego envía un enlace de phishing para que el objetivo le conceda acceso2. Una vez concedido el token, la aplicación puede obtener un acceso duradero a la cuenta, por ejemplo para buscar en el correo y listar los contactos26. El grupo APT28 utilizó aplicaciones disfrazadas de «Google Defender», «Google Email Protection» y «Google Scanner» para atacar a usuarios de Gmail2.
La cuenta única, punto de fallo
Quien posea un certificado de firma SAML válido puede falsificar tokens con los derechos y la duración que elija, y autenticarse así ante todos los servicios que usan SAML 2.0 para el SSO8. MITRE cita el compromiso de SolarWinds, en el que el grupo APT29 creó tokens con certificados de firma SAML comprometidos8.
4Casos reales1 min
2012: el envoltorio de firma XML
OWASP recuerda que en 2012 se describieron vulnerabilidades de implementaciones SAML vinculadas a ataques de envoltorio de firma XML7. Entre sus recomendaciones figura una validación segura de la firma digital7. Este trabajo corresponde a los equipos de informática, no al empleado.
Ficha
- Identificador
- CP-193
- Ala
- 3. Protocolos y defensa
- Competencia Brain
- Controlar los accesos (control_access)
- Reflejo Brain
- cr-025
- Esquema
- G3 · Corte anatómico
- Idiomas
- de, en, es, fr
- Fuentes
- 9 fuentes verificadas el 3 de noviembre de 2026
Fuentes9 fuentes
- NIST, «NIST Special Publication 800-63C». https://pages.nist.gov/800-63-3/sp800-63c.html (consultado el 3 de noviembre de 2026)
- MITRE ATT&CK, «Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1528/ (consultado el 3 de noviembre de 2026)
- MITRE ATT&CK, «Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1539/ (consultado el 3 de noviembre de 2026)
- Microsoft, «How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform». https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference (consultado el 3 de noviembre de 2026)
- Microsoft, «OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform». https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc (consultado el 3 de noviembre de 2026)
- MITRE ATT&CK, «Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1550/001/ (consultado el 3 de noviembre de 2026)
- OWASP, «SAML Security - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html (consultado el 3 de noviembre de 2026)
- MITRE ATT&CK, «Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1606/002/ (consultado el 3 de noviembre de 2026)
- NIST, «SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC». https://csrc.nist.gov/pubs/sp/800/63/c/4/final (consultado el 3 de noviembre de 2026)
Citar este artículo
Brain, «El SSO: SAML y OpenID Connect explicados de forma sencilla», Cyberpedia, 2026. https:/
BibTeX
@misc{brain_cp193_es_2026,
author = {Brain},
title = {El SSO: SAML y OpenID Connect explicados de forma sencilla},
year = {2026},
howpublished = {Cyberpedia},
url = {https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/},
note = {CC BY 4.0}
}