¿Cuál es la diferencia entre OpenID y SAML?

¿Cuál es la diferencia entre OpenID y SAML?

OpenID 2.0 original vs SAML

Son dos protocolos diferentes de autenticación y difieren a nivel técnico.

Desde la distancia, las diferencias comienzan cuando los usuarios inician la autenticación. Con OpenID, el inicio de sesión de un usuario suele ser una dirección HTTP del recurso que es responsable de la autenticación. Por otro lado, SAML se basa en una confianza explícita entre su sitio y el proveedor de identidad, por lo que es bastante raro aceptar credenciales de un sitio desconocido.

Las identidades de OpenID son fáciles de recorrer en la red. Como desarrollador, puede aceptar usuarios que provienen de proveedores de OpenID muy diferentes. Por otro lado, un proveedor de SAML generalmente debe codificarse por adelantado y usted federa su aplicación solo con proveedores de identidad seleccionados. Es posible reducir la lista de proveedores de identidad de OpenID aceptados, pero creo que esto estaría en contra del concepto general de OpenID.

Con OpenID, acepta identidades provenientes de servidores arbitrarios. Alguien dice ser http://someopenid.provider.com/john.smith. ¿Cómo va a hacer coincidir esto con un usuario en su base de datos? De alguna manera, por ejemplo, almacenando esta información con una nueva cuenta y reconociendo esto cuando el usuario visita su sitio nuevamente. ¡Tenga en cuenta que no se puede confiar en ninguna otra información sobre el usuario (incluido su nombre o correo electrónico)!

Por otro lado, si existe una confianza explícita entre su aplicación y el Proveedor de Id. De SAML, puede obtener información completa sobre el usuario, incluido el nombre y el correo electrónico, y se puede confiar en esta información, solo por la relación de confianza. Significa que tiende a creer que el proveedor de Id de alguna manera validó toda la información y puede confiar en ella a nivel de aplicación. Si los usuarios vienen con tokens SAML emitidos por un proveedor desconocido, su aplicación simplemente rechaza la autenticación.

OpenID Connect vs SAML

(sección agregada 07-2017, expandida 08-2018)

Esta respuesta data de 2011 y en ese momento OpenID significaba OpenID 2.0 . Más adelante, en algún lugar de 2012, se publicó OAuth2.0 y en 2014, OpenID Connect (una línea de tiempo más detallada aquí ).

Para cualquiera que lea esto hoy en día: OpenID Connect no es el mismo OpenID al que se refiere la respuesta original , sino que es un conjunto de extensiones para OAuth2.0.

Si bien esta respuesta puede arrojar algo de luz desde el punto de vista conceptual, una versión muy concisa para alguien que viene con antecedentes de OAuth2.0 es que OpenID Connect es de hecho OAuth2.0 pero agrega una forma estándar de consultar la información del usuario , después del token de acceso está disponible.

Refiriéndose a la pregunta original: ¿cuál es la principal diferencia entre OpenID Connect (OAuth2.0) y SAML? ¿Cómo se construye la relación de confianza entre la aplicación y el proveedor de identidad?

• SAML construye la relación de confianza en una firma digital, los tokens SAML emitidos por el proveedor de identidad son XML firmados, la aplicación valida la firma y el certificado que presenta. La información del usuario se incluye en un token SAML, entre otra información.

• OAuth2 construye la relación de confianza en una llamada HTTPs directa desde la aplicación a la identidad. La solicitud contiene el token de acceso (obtenido por la aplicación durante el flujo del protocolo) y la respuesta contiene la información sobre el usuario.

• OpenID Connect amplía aún más esto para que sea posible obtener la identidad sin este paso adicional que involucra la llamada de la aplicación al proveedor de identidad. La idea se basa en el hecho de que los proveedores de OpenID Connect de hecho emiten dos tokens, el access_tokenmismo OAuth2.0 y el nuevo, id_tokenque es un token JWT , firmado por el proveedor de identidad. La aplicación puede usar id_tokenpara establecer una sesión local, en función de las notificaciones incluidas en el token JWT, pero id_token no se puede usar para consultar otros servicios, tales llamadas a servicios de terceros aún deben usar elaccess_token. Puede pensar en OpenID Connect como un híbrido entre SAML2 (token firmado) y OAuth2 (token de acceso), ya que OpenID Connect solo involucra ambos.

OpenID y SAML2 se basan en el mismo concepto de identidad federada. Los siguientes son algunas de las diferencias entre ellos.

1. SAML2 admite el cierre de sesión único, pero OpenID no
2. Los proveedores de servicios SAML2 están asociados con los proveedores de identidad SAML2, pero las partes que confían en OpenID no están asociadas con los proveedores de OpenID. OpenID tiene un protocolo de descubrimiento que descubre dinámicamente el proveedor de OpenID correspondiente, una vez que se proporciona un OpenID. SAML tiene un protocolo de descubrimiento basado en el Protocolo de servicio de descubrimiento de proveedores de identidad.
3. Con SAML2, el usuario está acoplado al IdP SAML2: su identificador SAML2 solo es válido para el IdP SAML2 que lo emitió. Pero con OpenID, usted posee su identificador y puede asignarlo a cualquier proveedor de OpenID que desee.
4. SAML2 tiene diferentes enlaces, mientras que el único enlace que tiene OpenID es HTTP
5. SAML2 puede ser iniciado por el proveedor de servicios (SP) o por el proveedor de identidad (IdP). Pero OpenID siempre inició SP.
6. SAML 2 se basa en XML, mientras que OpenID no.
7. La mayoría de las aplicaciones desarrolladas en los últimos 3 años solo admitían OpenID Connect.
8. El 92% de las solicitudes de autenticación 8B + que Microsoft Azure AD entregó en mayo de 2018 fueron de aplicaciones habilitadas para OpenID Connect.

Dejando a un lado los detalles técnicos, llegando bastante tarde a la fiesta, entiendo que la mayor diferencia entre SAML y otros estándares de autenticación (inc. OpenID) es que

SAML requiere que el proveedor de identidad (IDP) y el proveedor de servicios (SP) se conozcan de antemano , preconfigurados , autenticación estática y autorización. OpenId (+ Connect) no tiene ese requisito.

Esto es importante para los desplazados internos que desean un control total sobre quién accede a los datos. Parte del estándar es configurar lo que se proporciona a SP específicos.

Por ejemplo, un banco podría no querer que sus usuarios accedan a ningún servicio excepto algunos predefinidos (debido a regulaciones u otras reglas estrictas de seguridad).

Esto no significa que un IDP de OpenId no pueda imponer dicha restricción. Un implementador de OpenID puede controlar el acceso, pero ese no es el propósito de OpenID.

Aparte de la diferencia de control de acceso predefinida, estricta, estática, conceptualmente (no técnicamente), OpenID Connect y SAML son similares.

En pocas palabras, si es un SP, debe admitir lo que requieren sus clientes:

1. Si su cliente es un cliente final individual (usando su identificación de Google, por ejemplo), olvídese de SAML. Use OpenID Connect.
2. Si su cliente es un banco que quiere que sus empleados usen su servicio y exporten solo una lista estática de datos que proporcionará a su servicio, el banco probablemente querrá que usted admita SAML. El banco podría tener una implementación de OpenID con restricción de cliente, que será su día de suerte :)

Tanto SAML como OpenID pueden actuar como proveedores de identidad (IdP abreviado), es decir, protocolo de autenticación descentralizado (identidad de inicio de sesión único).

El S ecurity A ssertion M arkup L anguage ( SAML ) es un conjunto de perfiles para el intercambio de datos de autenticación y autorización a través de dominios de seguridad. En el modelo de dominio SAML, un proveedor de identidad es un tipo especial de autoridad de autenticación. Específicamente, un proveedor de identidad SAML es una entidad del sistema que emite aserciones de autenticación junto con un perfil SSO de SAML. Una parte confiable que consume estas afirmaciones de autenticación se denomina proveedor de servicios SAML. Fuente

O pen ID C onnect ( OIDC ) es una capa de autenticación sobre OAuth 2.0, un marco de autorización. El estándar es controlado por la Fundación OpenID. OAuth es para el protocolo de autorización, en lugar de un protocolo de autenticación y OpenID específicamente diseñado como un protocolo de autenticación. OIDC utiliza JSON Web Tokens (JWT) simples, que son más fáciles de consumir por JavaScript.

Escenario de caso de uso:

Use OAuth si sus usuarios solo desean iniciar sesión con Facebook o Twitter. Use OpenID si sus usuarios son barbaros que ejecutan sus propios proveedores de OpenID porque "no quieren que nadie más sea dueño de su identidad".

Fuente