【应用安全】在OAuth2和SAML之间进行选择的更新视图

我收到了很多关于我的文章《选择SSO策略：SAML vs OAuth2》的电子邮件。两个常见的问题似乎是：1）您是否对OAuth2做出了正确的决定；2）我应该选择SAML还是OAuth2？

第一个问题的答案很简单：是的，OAuth2是该应用程序的正确选择。集成本身很简单，它支持我们客户拥有的所有用例（包括他们支持本地应用程序的目标）。它至今仍在使用中，自最初部署以来，我们就不必对集成造成任何麻烦。

有两种方法可以考虑第二个问题。我的默认回答是使用OAuth2。如果你想知道为什么，那么你需要继续阅读。

在选择合适的解决方案之前，您需要弄清楚应用程序希望实现的等式的哪一部分。无论使用OAuth2还是SAML，您的应用程序（或平台）都可以扮演两个角色：资源服务器（也称为服务提供商）和授权服务器（也称身份提供商）。

作为资源服务器；不是授权服务器

如果你不希望你的应用程序存储用户凭据，但你希望用户能够使用他们在另一个站点（例如Google、Facebook、Twitter等）上可能拥有的凭据登录到你的应用，那么你的应用将是一个资源服务器。

这意味着谷歌、Facebook、Twitter等将成为授权服务器。作为资源服务器的好处是，实现和维护工作量要少得多，因为许多决策都是为您做的。潜在的缺点是你必须实现他们支持的授权流。

如果您希望支持用户从多个身份验证提供商登录（例如，用户可以从Twitter、Google或Facebook登录），那么您的应用程序需要根据其支持的内容实现一个或多个授权流。这可能意味着您最终实现了OAuth2、SAML、OAuth 1.0，或者可能是完全不同或自定义的东西。

幸运的是，在实践中，这并不是那么糟糕。通常有特定于身份验证提供程序的库可用于各种编程语言，这些库隐藏了授权流的复杂性，并为您的应用程序提供了一个更简单的接口，以便进行身份验证/授权。

以下是通常称为“社交身份提供者”的常见授权服务器列表：

• Google: OAuth 2.0
• Facebook: variant of OAuth 2.0
• Twitter: OAuth 1.0a for users and OAuth 2.0a for applications
• Yahoo: OAuth 2.0 for products like Yahoo Gemini and Yahoo Social APIs but for the rest its OAuth 1.0a
• LinkedIn: OAuth 2.0
• Github: OAuth 2.0

第三方SSO和本地凭据

当有人发现他们的应用程序是资源服务器时，一个常见的问题是：如果人们不想通过第三方登录，我还能让他们在我的网站上创建帐户并使用这些凭据登录吗？还是我的应用程序需要成为支持SSO的授权服务器？

不知为什么，人们觉得当他们的应用程序允许第三方身份验证时，他们的应用需要成为一个全面的SSO授权服务器。这是一个神话。这不是真的。

您的应用程序可以利用第三方SSO，并且仍然允许用户创建没有SSO的本地帐户。如果您希望其他站点、应用程序等使用您的应用程序进行身份验证/授权，您只需要将应用程序作为支持SSO的授权服务器。

作为授权服务器；不是资源服务器

如果应用程序的目标是管理用户凭据并允许其他站点、应用程序等使用这些凭据进行身份验证，则应用程序将扮演授权服务器的角色。

现在，在OAuth2和SAML之间做出决定变得很重要，因为您的应用程序将指示其他应用程序如何与它集成以进行身份验证/授权。

让我们来看看几个场景，看看你应该怎么做。

本机移动应用程序支持

您希望本地移动应用程序（没有web服务器支持）能够根据授权服务器进行身份验证吗？如果是，那么就使用OAuth2。事实上，您甚至不能考虑SAML，因为它的设计不支持本地应用程序授权流。

SAML与本地应用程序一起工作的唯一方法是应用程序提供商在某个地方拥有一个可以处理授权流的web服务器。这种解决方法将起作用，这也是Okta允许SAML与本机应用程序一起工作的方式。

这种解决方法的缺点是给第三方应用程序提供商带来了更多负担。他们再也不能只发送应用程序并使用您的服务进行认证；现在，他们还必须构建一个处理授权的web应用程序。

这听起来可能不是什么大事，但它是另一个需要构建、部署和维护的代码库和应用程序。哦，别忘了购买域名/SSL证书/主机，并使其保持最新。

如果您希望本机应用程序使用您的授权服务器，只需使用OAuth2即可。构建和维护OAuth2对您来说要简单得多，而且其他应用程序开发人员也更容易与之集成。

当您不关心本机移动应用程序时

当您只关心web应用程序（或具有实现身份验证解决方案的web服务器的本地应用程序）时，您实际上可以在OAuth2和SAML之间进行选择。这引出了一个问题：谁不想让本机应用程序进行身份验证？

现在，从身份验证流中删除本地移动应用程序支持是非常不切实际的。这使得新的基于SAML的身份验证流看起来非常徒劳，尽管我知道它在企业界仍然很流行。

当您从头开始构建授权服务器时，我的建议是从OAuth2开始。尽管SAML在技术上是一个选择，但在当今移动主导的世界中，这是一个时代错误。OAuth2要简单得多，而且花费更少。

通过阅读75页，您可以全面了解OAuth2在 RFC 6749 b中的工作原理，而SAML 2.0规范 (core, bindings, profiles, metadata, conformance) 总计265页。

在我看来，与SAML 2.0规范相比，RFC 6749也更容易阅读和理解。

购买和配置现成授权服务器

如果您所在的公司不想实施授权服务器，但想购买现成的产品进行配置，那么您可以选择以下选项：

• Okta –IDentity提供商即服务平台（IDaaS）。成本取决于您是只允许组织的内部用户登录，还是希望外部用户也登录。
• OneLogin –IDaaS
• Ping Federate–IDaaS和站点安装，封闭源代码。
• WSO2 Identity Server ––开源且技术上免费，但要使用它，您100%需要购买支持合同。
• Shibboleth –免费开源。
• Gluu –使用其他开源组件（如Shibboleth）构建的开源平台，您可以购买支持合同。

对于更多的选择 list，这里列出了Ping Federate的竞争对手。

 off-the-shelf i的好处是，这些产品中的大多数都支持大量现成的授权流（例如OAuth2、OAuth1.0a、SAML等）。如果您的团队不是一个开发团队，而是一个系统管理/集成团队，那么现成的产品看起来更具吸引力。

 off-the-shelf i 的缺点是，你会得到很多你不需要的东西，而且你必须忍受通常笨重的用户界面和配置文件来做你需要的事情。所有非IDaaS的现成产品都可能需要支持合同才能启动和运行。对于您的团队来说，不仅要了解产品，还要了解授权流程以及如何配置和使用它们，这是一个很大的学习曲线。

尽管如此，与雇佣一个开发团队并从头开始构建自己的平台相比，支付一份支持合同来让你站起来并继续下去可能会更便宜。在某些情况下，如果您需要对授权服务器产品进行任何类型的自定义集成或定制，则可能需要两者中的一点。

像Okta、OneLogin等IDaaS产品对我来说非常有趣，因为它们继续将负担转嫁给提供商。随着时间的推移，您似乎会有更少的头痛，因为您不必担心修补和升级本地安装。相反，一旦它们可用，您将自动获取其中的大部分。这里的缺点是定制和本地站点安装可能不是一个选项。

当OAuth2太开放时

关于OAuth2的一个常见抱怨是它不够具体，并且留下了太多的变化空间。例如，OAuth2没有指定您应该如何获取用户配置文件信息（如果有的话），但大多数OAuth2提供程序都提供了实现这一点的方法，不同的提供程序可能会有所不同。

输入 OpenID Connect；OAuth2之上的一层。从其站点OpenID Connect：

允许客户端基于授权服务器执行的身份验证验证最终用户的身份，并以可互操作和类似REST的方式获取有关最终用户的基本配置文件信息

今年早些时候，OpenID Connect的认证计划启动。最先自我认证的是谷歌、微软、Ping Identity、ForgeLock、野村研究所和PayPal。此外，Salesforce还支持OpenID Connect。

如果您担心互操作性，那么现在有许多供应商和产品都遵循相同的标准，使用OAuth2流检索用户配置文件信息，而且列表还在不断增加。

尽管OpenIDConnect相对较新，但它在过去两年中一直在开发中，并为各种编程语言开发了大量库（a large number of libraries ）。

当SAML是实际选项时

当您拥有已经使用SAML的遗留或企业基础设施时，SAML是一个真正的选择。当你想利用这个基础设施时，SAML是一个有力的竞争者。然而，随着OAuth2和OpenIDConnect的兴起，SAML将很快被降级为遗留基础设施和集成。

例如，Microsoft的云平台Azure Active Directory支持SAML SSO，但截至2014年9月，它发布了OAuth2和OpenID Connect以实现通用性。

总结

现在，我们都很好地理解了OAuth2和SAML之间的权衡，我们可以重新问一个问题：我应该使用SAML还是OAuth2？

经验法则是首先查看基于OAuth2的解决方案。如果您不能取消OAuth2的资格以满足您的需求，那么您将拥有一个适用于更多应用程序的解决方案，而且更易于构建、理解、集成和支持。

在必须进行SAML集成的情况下，您现在知道了它的一些局限性，您将看到您可能需要花费额外的精力或在哪里寻找第三方提供商。