¿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?SAML vs inicio de sesión federado con OAuth
Resuelven problemas diferentes.
SAML es un conjunto de normas que se han definido para compartir información acerca de quién es el usuario, lo que a su conjunto de atributos son, y le dará una forma de conceder/denegar el acceso a algo o incluso solicitar la autenticación.
OAuth es más acerca de cómo delegar el 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 ser de ayuda.
OAuth piensa en un twitter. Digamos que estás usando Google Buzz y Twitter, y quieres 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 desnudo 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 se preocupan por la autorización, casi se podría argumentar que la afirmación de la autenticación a través de SAML y OpenID.
SAML tiene una variedad de "perfiles" para elegir que permiten 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í:
Me cuesta entender la diferencia entre "iniciar sesión" y "autorizar". ¿Puedes dar un ejemplo ilustrando la diferencia? –
@TimCooper "iniciar sesión" es una terminología suelta para * autenticación * mientras que "autorizar" es autorización correcta ... [Un ejemplo según su solicitud] (http://stackoverflow.com/questions/6556522/authentication-versus-authorization) – quickshiftin
@quickshiftin Bien, entiendo esa distinción. Su respuesta parece implicar que SAML realiza la autenticación, mientras que OAuth hace la autorización. ¿Es eso correcto? O ambos hacen ambas cosas (en cuyo caso, todavía no sé cuál es la diferencia). –
Ellos se encargan de un caso de uso sutil
echar un vistazo a this simple explanation resumido aquí:
Muchas personas están confundidas acerca de las diferencias entre SAML, OpenID y OAuth, pero en realidad es muy simple. Aunque hay una superposición de , aquí hay una manera muy simple de distinguir entre el tres.
OpenID - inicio de sesión único para los consumidores
SAML - solo
OAuth de sesión para usuarios de la empresa - la autorización API entre aplicaciones
Para la gente confortables con patrones de diseño orientado a objetos, lo creo que hay un buen corolario para patrones de envoltura. Piense en Fachada, Decorador y Proxy patrones. Fundamentalmente, estos son todos iguales, son solo envoltorios ... La diferencia es la intención de cada patrón.
Del mismo modo, SAML, OAuth y OpenID toda facilitan intenciones diferentes a través de un mecanismo común subyacente, que es la redirección a una autoridad proveedor de servicios/identidad de algún tipo de interacción privada, seguida de la redirección a la tercera parte de origen aplicación
Mirando alrededor de la red, encontrará una superposición entre las capacidades de los protocolos. Authentication via 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.
A 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.
Gracias por actualizar el enlace @Sundeep – quickshiftin
El enlace está muerto – Gobliins
Enlace actualizado, sin embargo, el resumen que ya estaba en la respuesta es el mismo. – quickshiftin
SAML es para autenticación - se usa principalmente en Single Sign On escenario. OAuth es para la autorización de representaciones de recursos.
JSON Web Token (JWT) es una alternativa para SAML XML Tokens. JWT se puede utilizar con OAuth
Una buena referencia es SAML vs. OAuth: Which One Should I Use?
http: // stackoverflow.com/questions/27314076/difference-between-jwt-and-saml – Lijo
La federación términos realmente significa identidades de conexión a través de sistemas. Está relacionado con SSO, pero no son lo mismo. I Found this blog post really helpful in terms of what federation really means.
Todavía no entiendo la diferencia. "conceder/denegar el acceso" y "otorgar acceso a la API" suenan como lo mismo para mí. ¿Puedes dar 2 ejemplos que sean más similares, para que pueda ver las diferencias? P.ej. ¿por qué no podríamos usar SAML para establecer la confianza entre su aplicación y Twitter? ¿O por qué no puedes usar OAuth para que Hertz le informe a USAirways sobre el trato especial? –
Lo obtengo, pero siempre puedo hacer SSO con OAuth (solicitando acceso a una API que proporciona identidad). ¿Eso significa que OAuth puede hacer todo lo que SAML puede y más? – dirk