--- id: CP-193 slug: sso-saml-openid-connect lang: es title: "El SSO: SAML y OpenID Connect explicados de forma sencilla" description: Una sola cuenta abre varias aplicaciones gracias a un token. Qué hacen SAML y OpenID Connect, y cómo actuar ante las trampas. canonical_url: https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/ markdown_url: https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, «El SSO: SAML y OpenID Connect explicados de forma sencilla», Cyberpedia, 2026. https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/ (CC BY 4.0)" wing: 3 theme: control_access reflex: cr-025 schema: G3 updated: "2026-11-03" translations: es: https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/ fr: https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ en: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ de: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ it: https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect/ sources: - "n": 1 title: NIST Special Publication 800-63C publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63c.html accessed: "2026-11-03" - "n": 2 title: Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 3 title: Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 4 title: How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference accessed: "2026-11-03" - "n": 5 title: OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc accessed: "2026-11-03" - "n": 6 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 7 title: SAML Security - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: "Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1606/002/ accessed: "2026-11-03" - "n": 9 title: "SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC" publisher: NIST url: https://csrc.nist.gov/pubs/sp/800/63/c/4/final accessed: "2026-11-03" --- # El SSO: SAML y OpenID Connect explicados de forma sencilla 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 una [1]. 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. ## 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ña [2][3]. - 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. ## 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ón [1]. El NIST precisa que este mecanismo evita tener credenciales distintas para cada servicio [1]. ### ¿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ón [4]. 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 SAML [1]. ### ¿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ón [1], 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 factor [6], y las cookies de sesión pueden eludir algunos protocolos de autenticación multifactor [3]. ## Cómo funciona 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 afirma [4]. 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 persona [1]. 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 firma [4]. 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 tokens [5]. OWASP describe para SAML una respuesta que contiene la aserción firmada digitalmente con la clave privada del proveedor de identidad [7]. 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 token [8]. 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ón [1]. La versión SP 800-63C-4, fechada en julio de 2025, sustituye a la del 2 de marzo de 2020 [9]; por tanto, estos tres niveles no son la norma actual [1]. ## Qué hace usted - 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 phishing [3]. - 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 olvidada [6]. - 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ón [3]. En Microsoft, cerrar sesión pone fin a la sesión del usuario [5]. - Lea la ventana de solicitud de autorización antes de hacer clic. Pide al usuario que conceda permisos a una aplicación [5]. - 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ón [2]. ## Las trampas ### 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 real [3]. 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 inverso [2]. ### El robo de token o de sesión Los tokens de acceso sirven para hacer solicitudes autorizadas en nombre de un usuario [6]. Una vez robados, sustituyen a la contraseña: el grupo APT29 utiliza tokens robados para acceder a cuentas sin contraseña [2]. Estos accesos por API son difíciles de detectar, incluso para el proveedor, porque se parecen a un uso normal [6]. Cambiar la contraseña tampoco basta necesariamente para cortarlos [6]. Los tokens de actualización permiten obtener otros nuevos sin consultar al usuario [2]. ### 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 acceso [2]. 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 contactos [2][6]. El grupo APT28 utilizó aplicaciones disfrazadas de «Google Defender», «Google Email Protection» y «Google Scanner» para atacar a usuarios de Gmail [2]. ### 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 SSO [8]. MITRE cita el compromiso de SolarWinds, en el que el grupo APT29 creó tokens con certificados de firma SAML comprometidos [8]. ## Casos reales ### 2012: el envoltorio de firma XML OWASP recuerda que en 2012 se describieron vulnerabilidades de implementaciones SAML vinculadas a ataques de envoltorio de firma XML [7]. Entre sus recomendaciones figura una validación segura de la firma digital [7]. Este trabajo corresponde a los equipos de informática, no al empleado. ## Fuentes 1. NIST, «NIST Special Publication 800-63C». https://pages.nist.gov/800-63-3/sp800-63c.html (consultado el 3 de noviembre de 2026) 2. 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) 3. 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) 4. 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) 5. 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) 6. 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) 7. OWASP, «SAML Security - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html (consultado el 3 de noviembre de 2026) 8. 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) 9. 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) --- Fuente original: Cyberpedia, la enciclopedia pública de ciberseguridad e IA publicada por Brain. Versión canónica: https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/ Puede reutilizar este texto libremente bajo la licencia CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), siempre que cite «Brain, Cyberpedia» con un enlace a la dirección anterior.