SAML frente a OpenID (OIDC)

Escrito por David Worthington en April 12, 2023

Comparte este artículo

Existe un pequeño universo de protocolos/estándares de identidad y autenticación, cada uno con sus propias ventajas y diferencias. Este artículo explora la comparación entre SAML y OpenID Connect (OIDC), los escenarios en los que un u otro protocolo sería beneficioso para su organización y cómo contribuye cada uno a la gestión de identidades y accesos (IAM, por sus siglas en inglés). Ambos enfoques permiten el inicio de sesión único (SSO, por sus siglas en inglés), pero existen diferencias técnicas e ideológicas que deben evaluarse antes de iniciar el proyecto: SAML está más especializado en la concesión segura de acceso a sitios web a través de dominios, mientras que OIDC proporciona un contexto adicional para aplicaciones móviles y web.

SAML frente a OpenID (OIDC) 

Este artículo podría simplemente ofrecer una comparación entre Security Assertion Markup Language (SAML 2.0) y OAuth (Open Authorization). OAuth es la base de OIDC, pero OIDC amplía el primero con una capa de identidad para autenticar las cuentas de usuario existentes mediante un servicio descentralizado gestionado por la fundación sin fines de lucro OpenID. La comunidad de código abierto inició el desarrollo de OpenID en 2005 con el objetivo de que las identidades estuvieran descentralizadas y no fueran propiedad de terceros.  Existen ahora más de mil millones de cuentas de usuario habilitadas para OpenID en más de 50.000 sitios web, según la fundación. Es la administradora de la infraestructura que soporta la autenticación OIDC, su comunidad y cualquier operación legal o de gobierno. 

SAML 2.0, por su parte, es una norma abierta que desde 2003 proporciona autenticación y autorización entre proveedores de identidad (IdP, por sus siglas en inglés) comerciales y privados y proveedores de servicios (SP, por sus siglas en inglés). Comenzó como una forma de implementar el SSO utilizando un marco basado en XML para permitir que los proveedores de identidad y los servicios existieran de forma separada unos de otros, con una gestión de usuarios centralizada. Empecemos por examinar cómo funciona SAML, explorándolo componente por componente.

Cómo funciona SAML

SAML es un estándar abierto para la autenticación (y autorización, si es necesario) que proporciona acceso SSO a aplicaciones web a través de la federación de identidades. SAML retransmite credenciales de usuario desde un IdP que posee y mantiene identidades para verificar los derechos de acceso y los SP. Los proveedores de servicios requieren autenticación antes de conceder a los usuarios acceso al recurso. Cada usuario (o grupo) tiene atributos que describen la información de su perfil y afirman a qué están autorizados a acceder exactamente.

SAML utiliza documentos de metadatos en lenguaje de marcado extensible (XML, por sus siglas en inglés), llamados tokens SAML, para un proceso de aserción que verifica la identidad de un usuario y sus privilegios de acceso.

Los desarrolladores utilizan plugins SAML dentro de aplicaciones o recursos para una experiencia de inicio de sesión SSO que garantice que se siguen las prácticas de seguridad y que las credenciales/afirmaciones determinen quién puede acceder a una aplicación. Además, SAML puede utilizarse para controlar a qué recursos puede acceder una identidad en una aplicación. 

SAML se compone de varios componentes básicos que hacen posible el intercambio de información de usuario para el control de acceso, incluyendo IdP, cliente, atributos, hasta el SP. 

Proveedor de identidades (IdP)

Un IdP (por sus siglas en inglés) es un servicio que mantiene y gestiona las identidades digitales para verificar las credenciales de usuario a través de aplicaciones, redes y servicios web. Su función principal es salvaguardar la integridad de las credenciales de los usuarios y federar la identidad de los usuarios cuando se desean inicios de sesión SSO.

Cliente

Los clientes son los usuarios que se autentican en un servicio utilizando las credenciales gestionadas por un IdP. Por ejemplo, su empresa puede utilizar SAML para el acceso SSO a los servicios que necesita para trabajar, utilizando su dirección de correo electrónico y contraseña.

Atributo

SAML transfiere mensajes, denominados aserciones, de un IdP a un proveedor de servicios. Estas aserciones establecen todos los requisitos de seguridad relevantes para la transacción autenticando, autorizando y determinando el nivel de permisos que recibirá un cliente. Atributos como “dept”, “email” y “role” se utilizan para aplicar la gestión y el control de acceso. A veces, se utilizan atributos personalizados para que SAML pueda ampliarse para su uso con software personalizado.

Proveedor de servicios (SP)

Los proveedores de servicios son un recurso en el que los usuarios se autentican mediante SAML SSO, normalmente un sitio web privado o una aplicación. Reciben, aceptan o deniegan las aserciones de los IdP para cada perfil de cliente antes de conceder el acceso a los usuarios. Los SP envían solicitudes a los IdP para iniciar el proceso de autenticación, y la aserción del cliente se recibe como respuesta. En ocasiones, el proceso se invierte cuando un IdP inicia el flujo de inicio de sesión para confirmar la identidad del usuario. Puede iniciarse de ambas formas.

Cómo funciona OIDC

OIDC amplía el protocolo OAuth para que los servicios cliente (sus aplicaciones) verifiquen las identidades de los usuarios e intercambien información de perfil a través de proveedores OpenID mediante API RESTful que envían tokens web JSON (JWT) para compartir información durante el proceso de autenticación. Los proveedores son esencialmente servidores de autenticación. Muchos desarrolladores se sienten atraídos por este enfoque porque es altamente escalable, flexible entre plataformas y relativamente sencillo de implementar. Sus componentes principales son un flujo de trabajo de identificación de usuario único con fundamentos OAuth.

Autenticación de usuarios

Un propietario de recursos (sus usuarios) se autentica y está autorizado a acceder a una aplicación cliente mediante un servidor de autorización que concede un token de acceso que permite a las aplicaciones recibir información consentida de un punto final UserInfo. Un punto final UserInfo es un recurso protegido que se encuentra en un servidor OpenID y que contiene reclamaciones (afirmaciones) sobre cada usuario en un objeto JSON. La información de autenticación se codifica en un token de identificación que recibe la aplicación. Esta información se almacena en caché para un rendimiento escalable y personaliza la experiencia del usuario final.

Source: OpenID Foundation

Basado en el protocolo OAuth 2.0

OIDC se basa en el marco OAuth 2.0, un estándar que permite a aplicaciones y servicios de terceros acceder a recursos de identificación de usuarios. No se envían credenciales de usuario por cable ni se almacenan en servidores de terceros, lo que aumenta la seguridad y la facilidad de uso para los administradores de TI.

Similitudes

  • Ambos marcos son protocolos de identidad que hacen posible el SSO.
  • Ambos marcos son seguros, están bien documentados y han madurado.
  • Los usuarios se autentican a través de un IdP, normalmente una vez, y luego pueden acceder a otras aplicaciones que “confían” en el IdP. Algunos servicios de confianza cero (Zero Trust) se autentican en cada punto de la cadena y verifican periódicamente el acceso mediante otro método de autenticación.
  • El flujo de trabajo de inicio de sesión parece muy similar para el usuario final, que no tiene ninguna visibilidad de las diversas diferencias técnicas que se producen entre bastidores.

Diferencias

  • Muchos desarrolladores creen que OpenID Connect es más sencillo de implementar porque no hay manejo de XML.
  • OpenID carece de datos de autorización de usuarios (como permisos) y se centra principalmente en la afirmación de identidades. SAML es un sistema de intercambio de datos de identidad muy completo.
  • La autenticación está descentralizada con OpenID.
  • SAML utiliza aserciones frente a la arquitectura OpenID y OAuth de tokens de identificación.
  • OIDC está diseñado para cargas de trabajo de API y puede utilizarse para proteger API.

Casos prácticos

Los desarrolladores y las organizaciones de TI deben seleccionar la solución que mejor se adapte a sus casos de uso particulares. Sin embargo, a veces es posible utilizar más de una simultáneamente. En cualquier caso, los casos de uso se han desarrollado orgánicamente con el uso de OIDC para aplicaciones web y móviles de canal trasero que solicitan tokens de acceso. 

SAML se utiliza casi siempre para el acceso a sitios web de canal frontal en los que los usuarios son los que activan la aplicación para autenticarse. Esto último supone que las aplicaciones cliente (un servicio web) operan desde dispositivos distintos del propietario del recurso (usted). A continuación, se ofrecen algunas directrices generales para casos de uso:

  • Una aplicación móvil suele utilizar un servicio como OIDC, porque es más ligero y muchas de las funciones que utilizan los desarrolladores están preconfiguradas o disponibles en bibliotecas complementarias.
  • Las aplicaciones que tienen SAML incorporado son una obviedad, sólo tiene que utilizar SAML.
  • Utilice SAML para acceder a las aplicaciones de la empresa a través de un portal.
  • Proteger APIs o exponer APIs son servicios que requerirán OAuth 2.0 u OIDC.
  • En ocasiones, las empresas se decantan por SAML debido a su capacidad de personalización y priorización del intercambio seguro de datos. Los sectores regulados deberían optar casi siempre por SAML para proteger la información sensible de los usuarios.

Usando OIDC y SAML juntos

Estos protocolos no son mutuamente excluyentes. Considere la posibilidad de utilizar SAML para el SSO empresarial con el fin de asegurar el acceso a los recursos de su organización y OIDC para los casos de uso móvil que tienen altos requisitos de escalabilidad. Cada uno tiene sus propias ventajas inherentes y cualquiera de ellos puede proporcionar servicios SSO.

Más información

Si desea obtener más información sobre cómo combinar lo mejor de ambos mundos, utilizando SAML y OIDC, póngase en contacto con nosotros. La plataforma JumpCloud utiliza atributos de usuario para hacer sugerencias inteligentes de pertenencia a grupos, y mucho más. También puede explorar lo que JumpCloud puede ofrecerle programando una demostración personalizada gratuita.

David Worthington

I'm the JumpCloud Champion for Product, Security. JumpCloud and Microsoft certified, security analyst, a one-time tech journalist, and former IT director.

Continúa Aprendiendo con nuestro Newsletter