SAML 与使用 OAuth 的联合登录 [英] SAML vs federated login with OAuth

问题描述

SAML 和使用 OAuth 联合登录有什么区别?如果公司想要使用第三方 Web 应用，但又想要单点登录并成为身份验证机构，哪种解决方案更有意义?

What's the difference between SAML and federated login with OAuth? Which solution makes more sense, if a company wants to use a third-party webapp, and but also wants single sign-on and be the authentication authority?

推荐答案

他们解决不同的问题.

SAML 是一组已定义的标准共享有关用户是谁、他的属性集是什么的信息，并为您提供一种授予/拒绝访问某些内容甚至请求身份验证的方法.

SAML is a set of standards that have been defined to share information about who a user is, what his set of attributes are, and give you a way to grant/deny access to something or even request authentication.

OAuth 更多的是关于委派对某些东西的访问.您基本上是在允许某人像您一样行事".它最常用于授予可以代表您执行某些操作的访问 api.

OAuth is more about delegating access to something. You are basically allowing someone to "act" as you. Its most commonly used to grant access api's that can do something on your behalf.

它们是两种完全不同的东西.

They are two completely different things.

一些可能有帮助的例子.

Some examples that might help out.

OAuth 想想推特.假设您正在使用 Google Buzz 和 Twitter，并且您想编写一个应用程序以便能够保持两者同步.您基本上可以在您的应用程序和推特之间建立信任.第一次将应用程序链接到 twitter 时，您会按照经典提示登录 twitter，然后弹出确认框并询问您想授予对 «您的应用程序名称» 的访问权限吗?单击是"后，信任就建立了，现在您的应用程序可以在 Twitter 上充当您的角色.它可以阅读您的帖子，也可以制作新帖子.

OAuth think of an twitter. Lets say you are using Google Buzz and Twitter, and you want to write an app to be able to keep the two synchronised. You basically can establish trust between your app and twitter. First time you go to link the app to twitter, you do the classic prompt to log into twitter, and then that confirmation box pops up and asks "Would you like to grant access to «your app name»?" once you click "yes", the trust has been established, and now your app can act as you on Twitter. It can read your posts, as well as make new ones.

SAML - 对于 SAML，请考虑两个不相关的会员系统之间的某种协议".在我们的例子中，我们可以使用 US Airways 和 Hertz.没有可以将您从一个站点带到另一个站点的共享凭据集，但可以说 Hertz 想向全美航空公司提供交易".(当然我知道这是一个极端的例子，但请耐心等待).购买机票后，他们将免费为其主席成员提供汽车租赁服务.US Airways 和 Hertz 会建立某种形式的信任，以及某种方式来识别用户.在我们的例子中，我们的联合 ID"将是电子邮件地址，这将是 Hertz 相信美国航空公司身份提供商将提供准确且安全的令牌的一种信任方式集.预订航班后，美国航空公司身份提供商将生成一个令牌并填充他们如何对用户进行身份验证，以及关于此人的属性"，在我们的案例中，最重要的属性是他在美国航空公司的身份级别.填充令牌后，它会通过某种类型的引用传递它，或者将其编码到 url 中，一旦我们到达 Hertz，它就会查看令牌、验证它，现在可以允许免费租车了.

SAML - For SAML think of some type of "agreement" between two unrelated membership systems. In our case we can use US Airways and Hertz. There is no shared set of credentials that can take you from one site to another, but lets say Hertz wants to offer a "deal" to US Airways. (Granted I know this is an extreme example, but bear with me). After buying a flight, they will offer a free rental car to its Chairman members. US Airways and Hertz would setup some form of trust, and some way to identify the user. In our case our "federated id" would be the email address, and it would be a one way set of trust Hertz trusts that US Airways identity provider will deliver a token that is accurate and in a secure manner. After booking the flight US Airways identity provider would generate a token and populate how they have authenticated the user, as well as "attributes" about the person in our case the most important attribute would be his status level in US Airways. Once the token has been populated it passes it via some type of reference, or encoded in a url and once we get to Hertz, it looks at the token, validates it and now can allow for the free rental car.

这个 SAML 示例的问题在于它只是众多用例中的一个.SAML 是一种标准，您可以通过多种方式实现它.

The problem with this SAML example is it's only one specialized use case out of many. SAML is a standard and there are almost too many ways that you can implement it.

或者，如果您不关心授权，您几乎可以争辩说通过 SAML 和 OpenID.

Alternatively, if you dont care about authorization, you could almost argue that asserting authentication via SAML and OpenID.

这篇关于SAML 与使用 OAuth 的联合登录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！