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
![\"\"](\"https:\/\/jumpcloud.com\/\/wp-content\/uploads\/sites\/3\/2023\/04\/componentes-de-saml.jpg\")
<\/figure>\n\n\n\nC\u00f3mo funciona SAML<\/strong><\/h2>\n\n\n\nSAML 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\nUn 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\nLos 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\nSAML 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\nLos 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\nOIDC 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\nUn 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
![\"\"](\"https:\/\/jumpcloud.com\/\/wp-content\/uploads\/sites\/3\/2023\/04\/openid-connect-protocol.jpg\")
Source: OpenID Foundation<\/em><\/figcaption><\/figure>\n\n\n\nBasado en el protocolo OAuth 2.0<\/strong><\/h3>\n\n\n\nOIDC 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\n- Ambos marcos son protocolos de identidad que hacen posible el SSO.<\/li>\n\n\n\n
- Ambos marcos son seguros, est\u00e1n bien documentados y han madurado.<\/li>\n\n\n\n
- Los usuarios se autentican a trav\u00e9s de un IdP, normalmente una vez, y luego pueden acceder a otras aplicaciones que “conf\u00edan” en el IdP. Algunos servicios de confianza cero (Zero Trust<\/a>) se autentican en cada punto de la cadena y verifican peri\u00f3dicamente el acceso mediante otro m\u00e9todo de autenticaci\u00f3n.<\/li>\n\n\n\n
- El flujo de trabajo de inicio de sesi\u00f3n parece muy similar para el usuario final, que no tiene ninguna visibilidad de las diversas diferencias t\u00e9cnicas que se producen entre bastidores.<\/li>\n<\/ul>\n\n\n\n
Diferencias<\/strong><\/h2>\n\n\n\n\n- Muchos desarrolladores creen que OpenID Connect es m\u00e1s sencillo de implementar porque no hay manejo de XML.<\/li>\n\n\n\n
- OpenID carece de datos de autorizaci\u00f3n de usuarios (como permisos) y se centra principalmente en la afirmaci\u00f3n de identidades. SAML es un sistema de intercambio de datos de identidad muy completo.<\/li>\n\n\n\n
- La autenticaci\u00f3n est\u00e1 descentralizada con OpenID.<\/li>\n\n\n\n
- SAML utiliza aserciones frente a la arquitectura OpenID y OAuth de tokens de identificaci\u00f3n.<\/li>\n\n\n\n
- OIDC est\u00e1 dise\u00f1ado para cargas de trabajo de API y puede utilizarse para proteger API.<\/li>\n<\/ul>\n\n\n\n
Casos pr\u00e1cticos<\/strong><\/h2>\n\n\n\nLos desarrolladores y las organizaciones de TI deben seleccionar la soluci\u00f3n que mejor se adapte a sus casos de uso particulares. Sin embargo, a veces es posible utilizar m\u00e1s de una simult\u00e1neamente. En cualquier caso, los casos de uso se han desarrollado org\u00e1nicamente con el uso de OIDC para aplicaciones web y m\u00f3viles de canal trasero que solicitan tokens de acceso. <\/p>\n\n\n\n
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\u00f3n para autenticarse. Esto \u00faltimo supone que las aplicaciones cliente (un servicio web) operan desde dispositivos distintos del propietario del recurso (usted). A continuaci\u00f3n, se ofrecen algunas directrices generales para casos de uso:<\/p>\n\n\n\n
\n- Una aplicaci\u00f3n m\u00f3vil suele utilizar un servicio como OIDC, porque es m\u00e1s ligero y muchas de las funciones que utilizan los desarrolladores est\u00e1n preconfiguradas o disponibles en bibliotecas complementarias.<\/li>\n\n\n\n
- Las aplicaciones que tienen SAML incorporado son una obviedad, s\u00f3lo tiene que utilizar SAML.<\/li>\n\n\n\n
- Utilice SAML para acceder a las aplicaciones de la empresa a trav\u00e9s de un portal.<\/li>\n\n\n\n
- Proteger APIs o exponer APIs son servicios que requerir\u00e1n OAuth 2.0 u OIDC.<\/li>\n\n\n\n
- En ocasiones, las empresas se decantan por SAML debido a su capacidad de personalizaci\u00f3n y priorizaci\u00f3n del intercambio seguro de datos. Los sectores regulados deber\u00edan optar casi siempre por SAML para proteger la informaci\u00f3n sensible de los usuarios.<\/li>\n<\/ul>\n\n\n\n
Usando OIDC y SAML juntos<\/strong><\/h2>\n\n\n\nEstos 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\u00f3n y OIDC para los casos de uso m\u00f3vil que tienen altos requisitos de escalabilidad. Cada uno tiene sus propias ventajas inherentes y cualquiera de ellos puede proporcionar servicios SSO.<\/p>\n\n\n\n
M\u00e1s informaci\u00f3n<\/strong><\/h2>\n\n\n\nSi desea obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo combinar lo mejor de ambos mundos, utilizando SAML y OIDC, p\u00f3ngase en contacto con nosotros<\/a>. La plataforma JumpCloud utiliza atributos de usuario para hacer sugerencias inteligentes de pertenencia a grupos, y mucho m\u00e1s. Tambi\u00e9n puede explorar lo que JumpCloud puede ofrecerle programando una demostraci\u00f3n personalizada gratuita<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
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\nLos 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\nSAML 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\nLos 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\nOIDC 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\nUn 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\nBasado en el protocolo OAuth 2.0<\/strong><\/h3>\n\n\n\nOIDC 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\n- Ambos marcos son protocolos de identidad que hacen posible el SSO.<\/li>\n\n\n\n
- Ambos marcos son seguros, est\u00e1n bien documentados y han madurado.<\/li>\n\n\n\n
- Los usuarios se autentican a trav\u00e9s de un IdP, normalmente una vez, y luego pueden acceder a otras aplicaciones que “conf\u00edan” en el IdP. Algunos servicios de confianza cero (Zero Trust<\/a>) se autentican en cada punto de la cadena y verifican peri\u00f3dicamente el acceso mediante otro m\u00e9todo de autenticaci\u00f3n.<\/li>\n\n\n\n
- El flujo de trabajo de inicio de sesi\u00f3n parece muy similar para el usuario final, que no tiene ninguna visibilidad de las diversas diferencias t\u00e9cnicas que se producen entre bastidores.<\/li>\n<\/ul>\n\n\n\n
Diferencias<\/strong><\/h2>\n\n\n\n\n- Muchos desarrolladores creen que OpenID Connect es m\u00e1s sencillo de implementar porque no hay manejo de XML.<\/li>\n\n\n\n
- OpenID carece de datos de autorizaci\u00f3n de usuarios (como permisos) y se centra principalmente en la afirmaci\u00f3n de identidades. SAML es un sistema de intercambio de datos de identidad muy completo.<\/li>\n\n\n\n
- La autenticaci\u00f3n est\u00e1 descentralizada con OpenID.<\/li>\n\n\n\n
- SAML utiliza aserciones frente a la arquitectura OpenID y OAuth de tokens de identificaci\u00f3n.<\/li>\n\n\n\n
- OIDC est\u00e1 dise\u00f1ado para cargas de trabajo de API y puede utilizarse para proteger API.<\/li>\n<\/ul>\n\n\n\n
Casos pr\u00e1cticos<\/strong><\/h2>\n\n\n\nLos desarrolladores y las organizaciones de TI deben seleccionar la soluci\u00f3n que mejor se adapte a sus casos de uso particulares. Sin embargo, a veces es posible utilizar m\u00e1s de una simult\u00e1neamente. En cualquier caso, los casos de uso se han desarrollado org\u00e1nicamente con el uso de OIDC para aplicaciones web y m\u00f3viles de canal trasero que solicitan tokens de acceso. <\/p>\n\n\n\n
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\u00f3n para autenticarse. Esto \u00faltimo supone que las aplicaciones cliente (un servicio web) operan desde dispositivos distintos del propietario del recurso (usted). A continuaci\u00f3n, se ofrecen algunas directrices generales para casos de uso:<\/p>\n\n\n\n
\n- Una aplicaci\u00f3n m\u00f3vil suele utilizar un servicio como OIDC, porque es m\u00e1s ligero y muchas de las funciones que utilizan los desarrolladores est\u00e1n preconfiguradas o disponibles en bibliotecas complementarias.<\/li>\n\n\n\n
- Las aplicaciones que tienen SAML incorporado son una obviedad, s\u00f3lo tiene que utilizar SAML.<\/li>\n\n\n\n
- Utilice SAML para acceder a las aplicaciones de la empresa a trav\u00e9s de un portal.<\/li>\n\n\n\n
- Proteger APIs o exponer APIs son servicios que requerir\u00e1n OAuth 2.0 u OIDC.<\/li>\n\n\n\n
- En ocasiones, las empresas se decantan por SAML debido a su capacidad de personalizaci\u00f3n y priorizaci\u00f3n del intercambio seguro de datos. Los sectores regulados deber\u00edan optar casi siempre por SAML para proteger la informaci\u00f3n sensible de los usuarios.<\/li>\n<\/ul>\n\n\n\n
Usando OIDC y SAML juntos<\/strong><\/h2>\n\n\n\nEstos 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\u00f3n y OIDC para los casos de uso m\u00f3vil que tienen altos requisitos de escalabilidad. Cada uno tiene sus propias ventajas inherentes y cualquiera de ellos puede proporcionar servicios SSO.<\/p>\n\n\n\n
M\u00e1s informaci\u00f3n<\/strong><\/h2>\n\n\n\nSi desea obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo combinar lo mejor de ambos mundos, utilizando SAML y OIDC, p\u00f3ngase en contacto con nosotros<\/a>. La plataforma JumpCloud utiliza atributos de usuario para hacer sugerencias inteligentes de pertenencia a grupos, y mucho m\u00e1s. Tambi\u00e9n puede explorar lo que JumpCloud puede ofrecerle programando una demostraci\u00f3n personalizada gratuita<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
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\nLos 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\nOIDC 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\nUn 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\nBasado en el protocolo OAuth 2.0<\/strong><\/h3>\n\n\n\nOIDC 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\n- Ambos marcos son protocolos de identidad que hacen posible el SSO.<\/li>\n\n\n\n
- Ambos marcos son seguros, est\u00e1n bien documentados y han madurado.<\/li>\n\n\n\n
- Los usuarios se autentican a trav\u00e9s de un IdP, normalmente una vez, y luego pueden acceder a otras aplicaciones que “conf\u00edan” en el IdP. Algunos servicios de confianza cero (Zero Trust<\/a>) se autentican en cada punto de la cadena y verifican peri\u00f3dicamente el acceso mediante otro m\u00e9todo de autenticaci\u00f3n.<\/li>\n\n\n\n
- El flujo de trabajo de inicio de sesi\u00f3n parece muy similar para el usuario final, que no tiene ninguna visibilidad de las diversas diferencias t\u00e9cnicas que se producen entre bastidores.<\/li>\n<\/ul>\n\n\n\n
Diferencias<\/strong><\/h2>\n\n\n\n\n- Muchos desarrolladores creen que OpenID Connect es m\u00e1s sencillo de implementar porque no hay manejo de XML.<\/li>\n\n\n\n
- OpenID carece de datos de autorizaci\u00f3n de usuarios (como permisos) y se centra principalmente en la afirmaci\u00f3n de identidades. SAML es un sistema de intercambio de datos de identidad muy completo.<\/li>\n\n\n\n
- La autenticaci\u00f3n est\u00e1 descentralizada con OpenID.<\/li>\n\n\n\n
- SAML utiliza aserciones frente a la arquitectura OpenID y OAuth de tokens de identificaci\u00f3n.<\/li>\n\n\n\n
- OIDC est\u00e1 dise\u00f1ado para cargas de trabajo de API y puede utilizarse para proteger API.<\/li>\n<\/ul>\n\n\n\n
Casos pr\u00e1cticos<\/strong><\/h2>\n\n\n\nLos desarrolladores y las organizaciones de TI deben seleccionar la soluci\u00f3n que mejor se adapte a sus casos de uso particulares. Sin embargo, a veces es posible utilizar m\u00e1s de una simult\u00e1neamente. En cualquier caso, los casos de uso se han desarrollado org\u00e1nicamente con el uso de OIDC para aplicaciones web y m\u00f3viles de canal trasero que solicitan tokens de acceso. <\/p>\n\n\n\n
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\u00f3n para autenticarse. Esto \u00faltimo supone que las aplicaciones cliente (un servicio web) operan desde dispositivos distintos del propietario del recurso (usted). A continuaci\u00f3n, se ofrecen algunas directrices generales para casos de uso:<\/p>\n\n\n\n
\n- Una aplicaci\u00f3n m\u00f3vil suele utilizar un servicio como OIDC, porque es m\u00e1s ligero y muchas de las funciones que utilizan los desarrolladores est\u00e1n preconfiguradas o disponibles en bibliotecas complementarias.<\/li>\n\n\n\n
- Las aplicaciones que tienen SAML incorporado son una obviedad, s\u00f3lo tiene que utilizar SAML.<\/li>\n\n\n\n
- Utilice SAML para acceder a las aplicaciones de la empresa a trav\u00e9s de un portal.<\/li>\n\n\n\n
- Proteger APIs o exponer APIs son servicios que requerir\u00e1n OAuth 2.0 u OIDC.<\/li>\n\n\n\n
- En ocasiones, las empresas se decantan por SAML debido a su capacidad de personalizaci\u00f3n y priorizaci\u00f3n del intercambio seguro de datos. Los sectores regulados deber\u00edan optar casi siempre por SAML para proteger la informaci\u00f3n sensible de los usuarios.<\/li>\n<\/ul>\n\n\n\n
Usando OIDC y SAML juntos<\/strong><\/h2>\n\n\n\nEstos 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\u00f3n y OIDC para los casos de uso m\u00f3vil que tienen altos requisitos de escalabilidad. Cada uno tiene sus propias ventajas inherentes y cualquiera de ellos puede proporcionar servicios SSO.<\/p>\n\n\n\n
M\u00e1s informaci\u00f3n<\/strong><\/h2>\n\n\n\nSi desea obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo combinar lo mejor de ambos mundos, utilizando SAML y OIDC, p\u00f3ngase en contacto con nosotros<\/a>. La plataforma JumpCloud utiliza atributos de usuario para hacer sugerencias inteligentes de pertenencia a grupos, y mucho m\u00e1s. Tambi\u00e9n puede explorar lo que JumpCloud puede ofrecerle programando una demostraci\u00f3n personalizada gratuita<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
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\nUn 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\nBasado en el protocolo OAuth 2.0<\/strong><\/h3>\n\n\n\nOIDC 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\n- Ambos marcos son protocolos de identidad que hacen posible el SSO.<\/li>\n\n\n\n
- Ambos marcos son seguros, est\u00e1n bien documentados y han madurado.<\/li>\n\n\n\n
- Los usuarios se autentican a trav\u00e9s de un IdP, normalmente una vez, y luego pueden acceder a otras aplicaciones que “conf\u00edan” en el IdP. Algunos servicios de confianza cero (Zero Trust<\/a>) se autentican en cada punto de la cadena y verifican peri\u00f3dicamente el acceso mediante otro m\u00e9todo de autenticaci\u00f3n.<\/li>\n\n\n\n
- El flujo de trabajo de inicio de sesi\u00f3n parece muy similar para el usuario final, que no tiene ninguna visibilidad de las diversas diferencias t\u00e9cnicas que se producen entre bastidores.<\/li>\n<\/ul>\n\n\n\n
Diferencias<\/strong><\/h2>\n\n\n\n\n- Muchos desarrolladores creen que OpenID Connect es m\u00e1s sencillo de implementar porque no hay manejo de XML.<\/li>\n\n\n\n
- OpenID carece de datos de autorizaci\u00f3n de usuarios (como permisos) y se centra principalmente en la afirmaci\u00f3n de identidades. SAML es un sistema de intercambio de datos de identidad muy completo.<\/li>\n\n\n\n
- La autenticaci\u00f3n est\u00e1 descentralizada con OpenID.<\/li>\n\n\n\n
- SAML utiliza aserciones frente a la arquitectura OpenID y OAuth de tokens de identificaci\u00f3n.<\/li>\n\n\n\n
- OIDC est\u00e1 dise\u00f1ado para cargas de trabajo de API y puede utilizarse para proteger API.<\/li>\n<\/ul>\n\n\n\n
Casos pr\u00e1cticos<\/strong><\/h2>\n\n\n\nLos desarrolladores y las organizaciones de TI deben seleccionar la soluci\u00f3n que mejor se adapte a sus casos de uso particulares. Sin embargo, a veces es posible utilizar m\u00e1s de una simult\u00e1neamente. En cualquier caso, los casos de uso se han desarrollado org\u00e1nicamente con el uso de OIDC para aplicaciones web y m\u00f3viles de canal trasero que solicitan tokens de acceso. <\/p>\n\n\n\n
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\u00f3n para autenticarse. Esto \u00faltimo supone que las aplicaciones cliente (un servicio web) operan desde dispositivos distintos del propietario del recurso (usted). A continuaci\u00f3n, se ofrecen algunas directrices generales para casos de uso:<\/p>\n\n\n\n
\n- Una aplicaci\u00f3n m\u00f3vil suele utilizar un servicio como OIDC, porque es m\u00e1s ligero y muchas de las funciones que utilizan los desarrolladores est\u00e1n preconfiguradas o disponibles en bibliotecas complementarias.<\/li>\n\n\n\n
- Las aplicaciones que tienen SAML incorporado son una obviedad, s\u00f3lo tiene que utilizar SAML.<\/li>\n\n\n\n
- Utilice SAML para acceder a las aplicaciones de la empresa a trav\u00e9s de un portal.<\/li>\n\n\n\n
- Proteger APIs o exponer APIs son servicios que requerir\u00e1n OAuth 2.0 u OIDC.<\/li>\n\n\n\n
- En ocasiones, las empresas se decantan por SAML debido a su capacidad de personalizaci\u00f3n y priorizaci\u00f3n del intercambio seguro de datos. Los sectores regulados deber\u00edan optar casi siempre por SAML para proteger la informaci\u00f3n sensible de los usuarios.<\/li>\n<\/ul>\n\n\n\n
Usando OIDC y SAML juntos<\/strong><\/h2>\n\n\n\nEstos 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\u00f3n y OIDC para los casos de uso m\u00f3vil que tienen altos requisitos de escalabilidad. Cada uno tiene sus propias ventajas inherentes y cualquiera de ellos puede proporcionar servicios SSO.<\/p>\n\n\n\n
M\u00e1s informaci\u00f3n<\/strong><\/h2>\n\n\n\nSi desea obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo combinar lo mejor de ambos mundos, utilizando SAML y OIDC, p\u00f3ngase en contacto con nosotros<\/a>. La plataforma JumpCloud utiliza atributos de usuario para hacer sugerencias inteligentes de pertenencia a grupos, y mucho m\u00e1s. Tambi\u00e9n puede explorar lo que JumpCloud puede ofrecerle programando una demostraci\u00f3n personalizada gratuita<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Basado en el protocolo OAuth 2.0<\/strong><\/h3>\n\n\n\nOIDC 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\n- Ambos marcos son protocolos de identidad que hacen posible el SSO.<\/li>\n\n\n\n
- Ambos marcos son seguros, est\u00e1n bien documentados y han madurado.<\/li>\n\n\n\n
- Los usuarios se autentican a trav\u00e9s de un IdP, normalmente una vez, y luego pueden acceder a otras aplicaciones que “conf\u00edan” en el IdP. Algunos servicios de confianza cero (Zero Trust<\/a>) se autentican en cada punto de la cadena y verifican peri\u00f3dicamente el acceso mediante otro m\u00e9todo de autenticaci\u00f3n.<\/li>\n\n\n\n
- El flujo de trabajo de inicio de sesi\u00f3n parece muy similar para el usuario final, que no tiene ninguna visibilidad de las diversas diferencias t\u00e9cnicas que se producen entre bastidores.<\/li>\n<\/ul>\n\n\n\n
Diferencias<\/strong><\/h2>\n\n\n\n\n- Muchos desarrolladores creen que OpenID Connect es m\u00e1s sencillo de implementar porque no hay manejo de XML.<\/li>\n\n\n\n
- OpenID carece de datos de autorizaci\u00f3n de usuarios (como permisos) y se centra principalmente en la afirmaci\u00f3n de identidades. SAML es un sistema de intercambio de datos de identidad muy completo.<\/li>\n\n\n\n
- La autenticaci\u00f3n est\u00e1 descentralizada con OpenID.<\/li>\n\n\n\n
- SAML utiliza aserciones frente a la arquitectura OpenID y OAuth de tokens de identificaci\u00f3n.<\/li>\n\n\n\n
- OIDC est\u00e1 dise\u00f1ado para cargas de trabajo de API y puede utilizarse para proteger API.<\/li>\n<\/ul>\n\n\n\n
Casos pr\u00e1cticos<\/strong><\/h2>\n\n\n\nLos desarrolladores y las organizaciones de TI deben seleccionar la soluci\u00f3n que mejor se adapte a sus casos de uso particulares. Sin embargo, a veces es posible utilizar m\u00e1s de una simult\u00e1neamente. En cualquier caso, los casos de uso se han desarrollado org\u00e1nicamente con el uso de OIDC para aplicaciones web y m\u00f3viles de canal trasero que solicitan tokens de acceso. <\/p>\n\n\n\n
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\u00f3n para autenticarse. Esto \u00faltimo supone que las aplicaciones cliente (un servicio web) operan desde dispositivos distintos del propietario del recurso (usted). A continuaci\u00f3n, se ofrecen algunas directrices generales para casos de uso:<\/p>\n\n\n\n
\n- Una aplicaci\u00f3n m\u00f3vil suele utilizar un servicio como OIDC, porque es m\u00e1s ligero y muchas de las funciones que utilizan los desarrolladores est\u00e1n preconfiguradas o disponibles en bibliotecas complementarias.<\/li>\n\n\n\n
- Las aplicaciones que tienen SAML incorporado son una obviedad, s\u00f3lo tiene que utilizar SAML.<\/li>\n\n\n\n
- Utilice SAML para acceder a las aplicaciones de la empresa a trav\u00e9s de un portal.<\/li>\n\n\n\n
- Proteger APIs o exponer APIs son servicios que requerir\u00e1n OAuth 2.0 u OIDC.<\/li>\n\n\n\n
- En ocasiones, las empresas se decantan por SAML debido a su capacidad de personalizaci\u00f3n y priorizaci\u00f3n del intercambio seguro de datos. Los sectores regulados deber\u00edan optar casi siempre por SAML para proteger la informaci\u00f3n sensible de los usuarios.<\/li>\n<\/ul>\n\n\n\n
Usando OIDC y SAML juntos<\/strong><\/h2>\n\n\n\nEstos 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\u00f3n y OIDC para los casos de uso m\u00f3vil que tienen altos requisitos de escalabilidad. Cada uno tiene sus propias ventajas inherentes y cualquiera de ellos puede proporcionar servicios SSO.<\/p>\n\n\n\n
M\u00e1s informaci\u00f3n<\/strong><\/h2>\n\n\n\nSi desea obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo combinar lo mejor de ambos mundos, utilizando SAML y OIDC, p\u00f3ngase en contacto con nosotros<\/a>. La plataforma JumpCloud utiliza atributos de usuario para hacer sugerencias inteligentes de pertenencia a grupos, y mucho m\u00e1s. Tambi\u00e9n puede explorar lo que JumpCloud puede ofrecerle programando una demostraci\u00f3n personalizada gratuita<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
- \n
- Ambos marcos son protocolos de identidad que hacen posible el SSO.<\/li>\n\n\n\n
- Ambos marcos son seguros, est\u00e1n bien documentados y han madurado.<\/li>\n\n\n\n
- Los usuarios se autentican a trav\u00e9s de un IdP, normalmente una vez, y luego pueden acceder a otras aplicaciones que “conf\u00edan” en el IdP. Algunos servicios de confianza cero (Zero Trust<\/a>) se autentican en cada punto de la cadena y verifican peri\u00f3dicamente el acceso mediante otro m\u00e9todo de autenticaci\u00f3n.<\/li>\n\n\n\n
- El flujo de trabajo de inicio de sesi\u00f3n parece muy similar para el usuario final, que no tiene ninguna visibilidad de las diversas diferencias t\u00e9cnicas que se producen entre bastidores.<\/li>\n<\/ul>\n\n\n\n
Diferencias<\/strong><\/h2>\n\n\n\n
- \n
- Muchos desarrolladores creen que OpenID Connect es m\u00e1s sencillo de implementar porque no hay manejo de XML.<\/li>\n\n\n\n
- OpenID carece de datos de autorizaci\u00f3n de usuarios (como permisos) y se centra principalmente en la afirmaci\u00f3n de identidades. SAML es un sistema de intercambio de datos de identidad muy completo.<\/li>\n\n\n\n
- La autenticaci\u00f3n est\u00e1 descentralizada con OpenID.<\/li>\n\n\n\n
- SAML utiliza aserciones frente a la arquitectura OpenID y OAuth de tokens de identificaci\u00f3n.<\/li>\n\n\n\n
- OIDC est\u00e1 dise\u00f1ado para cargas de trabajo de API y puede utilizarse para proteger API.<\/li>\n<\/ul>\n\n\n\n
Casos pr\u00e1cticos<\/strong><\/h2>\n\n\n\n
Los desarrolladores y las organizaciones de TI deben seleccionar la soluci\u00f3n que mejor se adapte a sus casos de uso particulares. Sin embargo, a veces es posible utilizar m\u00e1s de una simult\u00e1neamente. En cualquier caso, los casos de uso se han desarrollado org\u00e1nicamente con el uso de OIDC para aplicaciones web y m\u00f3viles de canal trasero que solicitan tokens de acceso. <\/p>\n\n\n\n
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\u00f3n para autenticarse. Esto \u00faltimo supone que las aplicaciones cliente (un servicio web) operan desde dispositivos distintos del propietario del recurso (usted). A continuaci\u00f3n, se ofrecen algunas directrices generales para casos de uso:<\/p>\n\n\n\n
- \n
- Una aplicaci\u00f3n m\u00f3vil suele utilizar un servicio como OIDC, porque es m\u00e1s ligero y muchas de las funciones que utilizan los desarrolladores est\u00e1n preconfiguradas o disponibles en bibliotecas complementarias.<\/li>\n\n\n\n
- Las aplicaciones que tienen SAML incorporado son una obviedad, s\u00f3lo tiene que utilizar SAML.<\/li>\n\n\n\n
- Utilice SAML para acceder a las aplicaciones de la empresa a trav\u00e9s de un portal.<\/li>\n\n\n\n
- Proteger APIs o exponer APIs son servicios que requerir\u00e1n OAuth 2.0 u OIDC.<\/li>\n\n\n\n
- En ocasiones, las empresas se decantan por SAML debido a su capacidad de personalizaci\u00f3n y priorizaci\u00f3n del intercambio seguro de datos. Los sectores regulados deber\u00edan optar casi siempre por SAML para proteger la informaci\u00f3n sensible de los usuarios.<\/li>\n<\/ul>\n\n\n\n
Usando OIDC y SAML juntos<\/strong><\/h2>\n\n\n\n
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\u00f3n y OIDC para los casos de uso m\u00f3vil que tienen altos requisitos de escalabilidad. Cada uno tiene sus propias ventajas inherentes y cualquiera de ellos puede proporcionar servicios SSO.<\/p>\n\n\n\n
M\u00e1s informaci\u00f3n<\/strong><\/h2>\n\n\n\n
Si desea obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo combinar lo mejor de ambos mundos, utilizando SAML y OIDC, p\u00f3ngase en contacto con nosotros<\/a>. La plataforma JumpCloud utiliza atributos de usuario para hacer sugerencias inteligentes de pertenencia a grupos, y mucho m\u00e1s. Tambi\u00e9n puede explorar lo que JumpCloud puede ofrecerle programando una demostraci\u00f3n personalizada gratuita<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"