{"id":1072,"date":"2023-04-12T15:29:33","date_gmt":"2023-04-12T15:29:33","guid":{"rendered":"https:\/\/jumpcloud.com\/es\/?p=1072"},"modified":"2023-04-12T19:18:38","modified_gmt":"2023-04-12T19:18:38","slug":"saml-vs-openid","status":"publish","type":"post","link":"https:\/\/jumpcloud.com\/es\/blog\/saml-vs-openid","title":{"rendered":"SAML frente a OpenID (OIDC)"},"content":{"rendered":"\n

Existe un peque\u00f1o universo de protocolos\/est\u00e1ndares de identidad y autenticaci\u00f3n, cada uno con sus propias ventajas y diferencias. Este art\u00edculo explora la comparaci\u00f3n entre SAML y OpenID Connect (OIDC), los escenarios en los que un u otro protocolo ser\u00eda beneficioso para su organizaci\u00f3n y c\u00f3mo contribuye cada uno a la gesti\u00f3n de identidades y accesos (IAM, por sus siglas en ingl\u00e9s). Ambos enfoques permiten el inicio de sesi\u00f3n \u00fanico (SSO<\/a>, por sus siglas en ingl\u00e9s), pero existen diferencias t\u00e9cnicas e ideol\u00f3gicas que deben evaluarse antes de iniciar el proyecto: SAML est\u00e1 m\u00e1s especializado en la concesi\u00f3n segura de acceso a sitios web a trav\u00e9s de dominios, mientras que OIDC proporciona un contexto adicional para aplicaciones m\u00f3viles y web.<\/p>\n\n\n\n

SAML frente a OpenID (OIDC) <\/strong><\/h2>\n\n\n\n

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

SAML 2.0, por su parte, es una norma abierta que desde 2003 proporciona autenticaci\u00f3n y autorizaci\u00f3n entre proveedores de identidad (IdP, por sus siglas en ingl\u00e9s) comerciales y privados y proveedores de servicios (SP, por sus siglas en ingl\u00e9s). Comenz\u00f3 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\u00f3n de usuarios centralizada. Empecemos por examinar c\u00f3mo funciona SAML, explor\u00e1ndolo componente por componente.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

C\u00f3mo funciona SAML<\/strong><\/h2>\n\n\n\n

SAML es un est\u00e1ndar abierto para la autenticaci\u00f3n (y autorizaci\u00f3n, si es necesario) que proporciona acceso SSO a aplicaciones web a trav\u00e9s de la federaci\u00f3n 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\u00f3n antes de conceder a los usuarios acceso al recurso. Cada usuario (o grupo) tiene atributos que describen la informaci\u00f3n de su perfil y afirman a qu\u00e9 est\u00e1n autorizados a acceder exactamente.<\/p>\n\n\n\n

SAML utiliza documentos de metadatos en lenguaje de marcado extensible (XML, por sus siglas en ingl\u00e9s), llamados tokens SAML, para un proceso de aserci\u00f3n que verifica la identidad de un usuario y sus privilegios de acceso.<\/p>\n\n\n\n

Los desarrolladores utilizan plugins SAML dentro de aplicaciones o recursos para una experiencia de inicio de sesi\u00f3n SSO que garantice que se siguen las pr\u00e1cticas de seguridad y que las credenciales\/afirmaciones determinen qui\u00e9n puede acceder a una aplicaci\u00f3n. Adem\u00e1s, SAML puede utilizarse para controlar a qu\u00e9 recursos puede acceder una identidad en una aplicaci\u00f3n. <\/p>\n\n\n\n

SAML se compone de varios componentes b\u00e1sicos que hacen posible el intercambio de informaci\u00f3n de usuario para el control de acceso, incluyendo IdP, cliente, atributos, hasta el SP. <\/p>\n\n\n\n

Proveedor de identidades (IdP)<\/strong><\/h3>\n\n\n\n

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

Cliente<\/strong><\/h3>\n\n\n\n

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\u00f3n de correo electr\u00f3nico y contrase\u00f1a.<\/p>\n\n\n\n

Atributo<\/strong><\/h3>\n\n\n\n

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\u00f3n autenticando, autorizando y determinando el nivel de permisos que recibir\u00e1 un cliente. Atributos como “dept”, “email” y “role” se utilizan para aplicar la gesti\u00f3n y el control de acceso. A veces, se utilizan atributos personalizados para que SAML pueda ampliarse para su uso con software personalizado.<\/p>\n\n\n\n

Proveedor de servicios (SP)<\/strong><\/h3>\n\n\n\n

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\u00f3n. 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\u00edan solicitudes a los IdP para iniciar el proceso de autenticaci\u00f3n, y la aserci\u00f3n del cliente se recibe como respuesta. En ocasiones, el proceso se invierte cuando un IdP inicia el flujo de inicio de sesi\u00f3n para confirmar la identidad del usuario. Puede iniciarse de ambas formas.<\/p>\n\n\n\n

C\u00f3mo funciona OIDC<\/strong><\/h2>\n\n\n\n

OIDC ampl\u00eda el protocolo OAuth para que los servicios cliente (sus aplicaciones) verifiquen las identidades de los usuarios e intercambien informaci\u00f3n de perfil a trav\u00e9s de proveedores OpenID mediante API RESTful que env\u00edan tokens web JSON (JWT) para compartir informaci\u00f3n durante el proceso de autenticaci\u00f3n. Los proveedores son esencialmente servidores de autenticaci\u00f3n. Muchos desarrolladores se sienten atra\u00eddos 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\u00f3n de usuario \u00fanico con fundamentos OAuth.<\/p>\n\n\n\n

Autenticaci\u00f3n de usuarios<\/strong><\/h3>\n\n\n\n

Un propietario de recursos (sus usuarios) se autentica y est\u00e1 autorizado a acceder a una aplicaci\u00f3n cliente mediante un servidor de autorizaci\u00f3n que concede un token de acceso que permite a las aplicaciones recibir informaci\u00f3n 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\u00f3n de autenticaci\u00f3n se codifica en un token de identificaci\u00f3n que recibe la aplicaci\u00f3n. Esta informaci\u00f3n se almacena en cach\u00e9 para un rendimiento escalable y personaliza la experiencia del usuario final.<\/p>\n\n\n\n

\"\"
Source: OpenID Foundation<\/em><\/figcaption><\/figure>\n\n\n\n

Basado en el protocolo OAuth 2.0<\/strong><\/h3>\n\n\n\n

OIDC se basa en el marco OAuth 2.0, un est\u00e1ndar que permite a aplicaciones y servicios de terceros acceder a recursos de identificaci\u00f3n de usuarios. No se env\u00edan 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.<\/p>\n\n\n\n

Similitudes<\/strong><\/strong><\/strong><\/h2>\n\n\n\n