sso authentication oauth saml

authentication - sso - SAML vs inicio de sesión federado con OAuth



saml vs oauth2 (6)

¿Cuál es la diferencia entre SAML y el inicio de sesión federado con OAuth? ¿Qué solución tiene más sentido si una empresa quiere usar una aplicación web de terceros y también quiere un inicio de sesión único y ser la autoridad de autenticación?

Eche un vistazo a esta explicación simple resumida aquí:

Muchas personas están confundidas acerca de las diferencias entre SAML, OpenID y OAuth, pero en realidad es muy simple. Aunque hay cierta superposición, aquí hay una manera muy simple de distinguir entre los tres.

OpenID: inicio de sesión único para los consumidores

SAML: inicio de sesión único para usuarios empresariales

OAuth: autorización API entre aplicaciones

Para gente cómoda con los patrones de diseño de OO, creo que hay un buen corolario para los patrones de envoltura . Piensa en los patrones Facade , Decorator y Proxy . Fundamentalmente, estos son todos iguales, solo son envoltorios ... La diferencia es la intención de cada patrón .

Del mismo modo, SAML, OAuth y OpenID facilitan diferentes intenciones a través de un mecanismo subyacente común , que es la redirección a un proveedor de servicios / autoridad de identidad para alguna interacción privada, seguido de una redirección a la aplicación de origen de terceros.

Al mirar alrededor de la red, encontrará una superposición entre las capacidades de los protocolos. La autenticación a través de OAuth es perfectamente razonable. El SSO sobre OAuth puede no tener mucho sentido, ya que SAML y OpenID están específicamente orientados a la identidad federada.

Para la pregunta en sí, en un contexto corporativo, SAML suena más apropiado que OAuth para SSO . Apuesto a que si miras las aplicaciones de terceros que te gustaría integrar con tus identidades corporativas, verás que ya están diseñadas para integrarse con SAML / LDAP / Radius, etc. IMO OAuth es más apropiado para la interacción de Internet entre aplicaciones o quizás aplicaciones que comprenden una arquitectura orientada a servicios en un entorno corporativo grande.

Las reglas de autorización se pueden especificar en un entorno corporativo de otras maneras también. LDAP es una herramienta común para esto. Organizar a los usuarios en grupos y asociar los privilegios de las aplicaciones con la pertenencia a un grupo es un enfoque generalizado. Lo mismo ocurre LDAP también se puede utilizar para la autenticación. Active Directory es un gran ejemplo, aunque prefiero OpenLDAP.

Ellos resuelven diferentes problemas.

SAML es un conjunto de estándares que se han definido para compartir información sobre quién es un usuario, cuál es su conjunto de atributos y cómo otorgar / negar el acceso a algo o incluso solicitar la autenticación.

OAuth tiene más que ver con la delegación de acceso a algo. Básicamente estás permitiendo que alguien "actúe" como tú. Es el más comúnmente utilizado para otorgar acceso api que puede hacer algo en su nombre.

Son dos cosas completamente diferentes.

Algunos ejemplos que pueden ayudar.

OAuth piensa en un twitter. Digamos que está utilizando Google Buzz y Twitter, y desea escribir una aplicación para poder mantener los dos sincronizados. Básicamente puedes establecer confianza entre tu aplicación y Twitter. La primera vez que va a vincular la aplicación a Twitter, hace el clásico aviso para iniciar sesión en Twitter, y luego aparece el cuadro de confirmación y pregunta "¿Desea otorgar acceso a« el nombre de su aplicación »?" una vez que haga clic en "sí", se habrá establecido la confianza, y ahora su aplicación puede actuar como usted en Twitter. Puede leer tus publicaciones, así como también hacer otras nuevas.

SAML: para SAML, piense en algún tipo de "acuerdo" entre dos sistemas de membresía no relacionados. En nuestro caso, podemos usar US Airways y Hertz. No hay un conjunto compartido de credenciales que pueda llevarlo de un sitio a otro, pero digamos que Hertz quiere ofrecer un "trato" a US Airways. (Por supuesto, sé que este es un ejemplo extremo, pero tengan paciencia conmigo). Después de comprar un vuelo, ofrecerán un auto de alquiler gratuito a los miembros de su presidente. US Airways y Hertz establecerían alguna forma de confianza y una forma de identificar al usuario. En nuestro caso, nuestra "identificación federada" sería la dirección de correo electrónico, y sería un conjunto de confianzas de Hertz en un solo sentido que el proveedor de identidad de US Airways entregará un token que es preciso y de manera segura. Después de reservar el vuelo, el proveedor de identidad de US Airways generará un token y poblará cómo han autenticado al usuario, así como los "atributos" sobre la persona en nuestro caso, el atributo más importante sería su nivel de estado en US Airways. Una vez que el token ha sido poblado, lo pasa a través de algún tipo de referencia, o codificado en una url, y una vez que llegamos a Hertz, mira el token, lo valida y ahora puede permitir el alquiler gratuito del auto.

El problema con este ejemplo de SAML es que es solo un caso de uso especializado entre muchos. SAML es un estándar y existen muchas formas de implementarlo.

Alternativamente, si no le preocupa la autorización, casi podría argumentar que afirma la autenticación a través de SAML y OpenID .

Manejan un caso de uso sutil

  • SAML - Compartir credenciales (por ejemplo, SSO) de un usuario a varios proveedores de servicios (por ejemplo, web o servicio web)
  • OAuth: un usuario que delega una aplicación para acceder a un recurso en nombre de su / su

SAML tiene una variedad de "perfiles" para elegir y permite a otros usuarios "iniciar sesión" en su sitio. SAML-P o SAML pasivo es muy común y bastante simple de configurar. WS-Trust es similar y también permite la federación entre sitios web.

OAuth está diseñado para autorización. Puede leer más aquí:

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

SAML es para autenticación, se usa principalmente en el escenario de inicio de sesión único . OAuth es para autorización de representaciones de recursos.

JSON Web Token (JWT) es una alternativa para SAML XML Tokens. JWT se puede usar con OAuth

Una buena referencia es SAML vs. OAuth: ¿Cuál debo usar?