SAML 与 OAuth

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

工程师企业级单点登录指南

OAuth 和SAML都是开放规范，用于在身份提供商和应用程序之间交换特定用户的访问凭证。当用户想要使用 SAML 或 OAuth 登录应用程序时，他们会被重定向到一个第三方，用户必须事先在该第三方注册。用户在该第三方注册后，会被重定向回应用程序。虽然机制有所不同，但 SAML 和 OAuth 都涉及使用密钥来安全地交换用户信息，以便应用程序能够为用户建立经过身份验证的会话。

如果您以工程师的身份来研究这些技术，可以将 OAuth 理解为基于类的协议，而 SAML 则基于实例的协议。使用 OAuth，您只需将应用程序与 GitHub 等提供商进行配置，任何 GitHub 用户即可登录您的应用程序。但使用 SAML，您必须将应用程序与身份提供商 (IDP)实例进行配置。每个想要使用 SAML 的客户都会拥有一个与其 IDP 关联的实例，您和客户都必须在您的应用程序和他们的 IDP 实例之间进行配置。

虽然 SAML 和 OAuth 之间的区别看似微不足道，但随着你深入研究实例，你会发现实现 SAML 比实现 OAuth 要复杂得多——它需要 CRUD 和持久化功能、用于配置实例的 UI、面向客户和团队成员的文档，而且你还需要调整登录表单的工作方式。这些连锁反应远比 SAML 的细节更重要——就像现代 Web 开发中的大多数技术一样，虽然有很多强大的库可以处理这些细节，但它们只能帮你完成 90% 的工作，而无法构建一个可用于生产环境的集成。

OAuth 的简明个人史

我开始从事 Web 编程的时候，正值“社交网络 2.0”时代，OAuth无处不在。那是黑客马拉松的鼎盛时期，互联网更加有趣、轻松、天马行空。OAuth 不仅能帮助你更快地启动项目，绕过基于密码的身份验证，还能让你获得海量的用户数据，用于组合和创造各种体验——Facebook 好友、Foursquare 签到和推文……至少在 OAuth 成功阻止了 OAuth 崩溃之前是这样的。

OAuth 对普通网络用户来说非常方便。它最初的设计目的并非用于用户身份验证，但人们开始这样使用它，并且一直沿用至今。普通互联网用户无需记住数百个网站的密码，只需将 Facebook 帐户的密钥交给 OAuth，即可轻松登录。随着 OAuth 的普及，服务提供商、消费者工程师和用户逐渐掌握了权限范围的运用，从而限制了应用程序在已通过 OAuth 认证的帐户中可以代表用户执行的操作。

OAuth 太多了

OAuth 至今仍是一种流行的身份验证机制，广泛应用于消费者和企业应用程序。它的实现极其简便——许多编程语言和框架都提供了标准化的方法或库，简化了部署过程。例如，Ruby 中有一个名为 OmniAuth 的库，它“标准化了 Web 应用程序的多提供商身份验证”。任何开发者都可以为特定的 Web 服务创建 OmniAuth“策略”。Passport则为 NodeJS 应用程序提供了类似的解决方案。

通常情况下，您需要在 Web 服务的开发者门户注册您的应用程序，在那里您将获得客户端 ID 和客户端密钥，指定重定向 URI 并选择要使用的作用域。将这些密钥添加到您的应用程序中，引入 OAuth 库，不到一个小时即可完成。OAuth 对用户和工程师来说确实很方便，但对于大型企业或注重安全性的企业而言，SAML 才是他们及其员工的最佳选择（即使实施起来比较麻烦）。

让首席信息安全官们彻夜难眠

首席信息安全官 (CISO) 是组织信息和数据安全的最终负责人。逃避这一责任的一个好方法是允许员工使用密码或通过 OAuth 认证，从企业无法控制的身份提供商处注册关键应用程序和服务。例如，假设一名员工离职后，仍然使用电子邮件和密码或个人 Twitter 帐户登录所有服务。

IT部门需要在员工离职时立即切断其对各项服务的访问权限。他们需要进入每项服务的账户设置，并移除该用户。在企业规模下，每周可能有数十甚至数百名员工离职。管理账户访问权限将成为IT部门永无止境的噩梦。

SAML 将其锁定

再次强调，SAML 本身并不是关键所在。许多身份提供商 (IDP) 也支持其他凭证交换技术，例如 OAuth。但 SAML 是企业普遍采用的标准，并且受到所有企业级身份提供商的支持。

企业级身份提供商的关键在于集中管理用户对应用程序的访问权限。当员工离职时，IT 部门只需在一个地方移除该用户，该用户就会立即失去对其在工作中使用的所有服务的访问权限。SAML 代表“安全断言标记语言”，但在通常情况下，SAML 是一种身份验证机制，企业可以轻松地通过它关闭访问权限。企业要求您提供 SAML 身份验证，并非因为他们喜欢老旧笨拙的技术或想给您添麻烦——他们只是需要能够在一个地方管理员工对服务的访问权限。

SAML流程图

SAML 会降低你的速度

如果你需要添加 SAML，这对你的公司来说反而是个好消息！这意味着你正在向高端市场拓展，开始与规模更大、交易更频繁、客户忠诚度更高的公司合作。如果你正在考虑添加 SAML，你可能还有上千件其他事情要处理，比如扩展性问题、想要添加的功能以及需要解决的技术债务等等。但是，添加 SAML 或许是提升公司收入、赢得更多与大型公司合作机会的最有效途径。

问题在于，实现 SAML 比实现 OAuth 要复杂得多。当然，这并非难事——你不需要编写任何算法，而且有很多开源库可以用来处理从身份提供商 (IDP) 收到的 SAML 响应。但回到我们之前讨论的基于类和基于实例的区别，让我们回顾一下为了交付一个可用于生产环境的 SAML 集成，你需要完成哪些任务。

1. 配置用户界面和 CRUD

每个需要 SAML 的客户都需要进行注册，届时您的团队成员会向客户提供一些信息，例如断言消费者服务 URL 和实体 ID。这些信息都属于 SAML 规范的一部分，详细解释其功能超出了本文的范围，但您需要了解的是，您的应用程序需要生成这些值，并且每个客户的值都是唯一的。客户在其身份提供商 (IDP) 中配置您的应用程序后，会向您返回一些数据，通常以元数据 XML 文件的形式。您会解析该文件以获取需要持久化的密钥和 SSO URL 吗？还是让您的团队成员打开 XML 文件并复制数据？无论哪种方式，您都需要将所有信息持久化到数据库表中，并提供一种可靠的方法，以便在用户登录时查找这些信息。

2. 文档

你不能想当然地认为客户知道如何在他们的身份提供商 (IDP) 实例中设置 SAML 应用，所以你需要提供一些指导。这通常意味着注册所有常用的 IDP，仔细阅读他们的文档并配置一个测试应用，用你的代码库进行质量保证，最终创建一些文档来帮助你的客户。千万不要忽略这一步——这将是你宝贵的企业客户在签署协议后首先要体验的内容。

3. 登录用户体验

由于 SAML 身份验证是基于实例的，因此您需要通过客户返回的 SSO URL 将用户路由到正确的身份提供商 (IDP)。与 OAuth 不同，您不能简单地在登录页面上添加一个“使用 Okta 登录”按钮就万事大吉。两种常见的解决方法是：一是将登录表单拆分为两个步骤，首先获取用户的电子邮件地址，如果用户拥有企业 SAML 帐户，则将其发送给 IDP；二是创建第二个 SAML SSO 登录表单，仅收集电子邮件地址或公司域名。

这工作量可不小！如果你正在阅读这篇文章，我想我们可以假设你的支持团队成员可能并不了解 SAML，所以你可能也需要一些内部文档和培训。而且我们甚至还没深入探讨 SAML 规范本身！属性映射、单点注销等等，还有很多东西需要考虑。

Osso 允许您将 SAML 视为 OAuth。

你可能在职业生涯的某个阶段使用过 OAuth，甚至可能已经在当前的技术栈中使用它来实现诸如 Google 登录之类的功能。它的设置很简单——注册客户端，将一些重定向 URI 添加到允许列表，然后获取客户端 ID 和密钥。另一方面，SAML 虽然概念上类似，但需要为每个客户实例进行配置，这使得 SAML 集成的工作量更大一些。

Osso 允许您使用 OAuth 流程登录 SAML 用户——它是 SAML 作为 OAuth，而不是 SAML 与 OAuth 之间的冲突。Osso 处理所有 SAML 相关事宜——我们的管理界面简洁易用，即使是非技术团队成员也能轻松上手，方便客户注册，并为客户的身份提供商 (IDP) 生成自定义文档。当客户向您返回 XML 元数据文件时，您的团队成员可以轻松上传该文件，系统会自动解析并保存所需的值。Osso 提供 OmniAuth 和 Passport 的库，让您的集成更加便捷。您甚至可以保持现有的登录用户体验——Osso 提供托管的登录页面，您只需添加一个“使用 SSO 登录”按钮或链接即可（不过我们建议您最终通过向用户发送带有域名或电子邮件地址的 IDP 路由信息来深化集成）。