如何为集成选择最佳的身份验证方法？让我们看看 B2B SaaS 团队使用基本认证、 API 密钥和 OAuth 2.0的时间和原因

每天?分享?最新?软件?开发?，Devops，敏捷?，测试?以及?项目?管理?最新?，最热门?的?文章?，每天?花?3分钟?学习?何乐而不为?，希望?大家?点赞?，评论，加?关注?，你的?支持?是我?最大?的?动力?。

从软件开发的早期开始，身份验证(也称为 auth)就是必不可少的。为了确保系统和数据的安全性，必须确保只允许正确标识的用户登录到系统。

如果您正在构建本地集成，以将您的 SaaS 产品与客户使用的其他应用程序连接起来，那么其中一个棘手的问题就是处理第三方应用程序的细微差别，比如身份验证。有时候，您需要为自己的应用程序设置身份验证，有时候，您需要配置您的集成，以使用已提供的任何身份验证模式。在任何一种情况下，了解用户身份验证方法的工作原理以及查找内容都可以节省时间并避免集成方面的麻烦。

在与客户合作的过程中，我的团队帮助 SaaS 团队使用基本的身份验证、 API 密钥和 Open Auth 2.0(又名 OAuth 2.0)实现了本地集成，包括 OAuth 2.0的非规范变体。授权类型首选项肯定会随着时间的推移而改变，基本的身份验证在很长一段时间内都是首选方法，尽管大多数开发人员已经转向 API 密钥和 OAuth 2.0，原因我们很快就会讲到。

让我们看看这些主要的身份验证方法是如何工作的，并深入研究本机集成上下文中的细节。我们还会涉及授权(访问特定资源的权限) ，但这不是本文的重点。

了解基本认证方法

基本身份验证使用经典的用户名和密码方法。如前所述，这在现代 SaaS 应用程序中不再常见，但是我们仍然在许多遗留系统中看到它，包括 FTP 或旧的基于 HTTP 的应用程序。

对于 HTTP 中基本认证的最简单用例，使用用户名和密码，在它们之间放置一个: ，然后使用 base64对整个认证进行编码。然后，将整个 base-64编码的字符串作为 HTTP 请求的头部:

curl <https://example.com> \\
  --header "Authorization: Basic bXl1c2VyOm15UEBzU3cwUmQ="

为了确保它符合标准，始终使用具有 Basic { base64编码的用户名: 密码}值的标头的 Authorization 前缀。

更简单的方法是将用户名和密码放在 URL 的开头:

curl <https://myuser:myP%40sSw0rd@example.com>

然而，这种模式长期以来一直不受欢迎，因为在任何人都可以阅读的开放环境中输入凭证并不是一种好的安全实践。

为什么 SaaS 团队使用基本的认证方法进行集成

集成的基本身份验证非常简单: 基本身份验证非常容易实现。您所需要做的就是解码 base64编码的头文件，并验证用户名/密码组合是否正确。就是这样。由于其简单性，当您在内部构建自定义集成而不使用 API 或集成平台时，基本身份验证是有意义的。

使用基本身份验证方法进行集成时需要考虑的事项

虽然基本的认证很容易实现，但是它也有一些缺点。每个集成都获得相同的凭据，您不能限制凭据的作用域。也就是说，您不能更改绑定到凭据的授权。因此，每个集成都可以执行凭据所允许的任何操作。而且，如果要更改凭据，那么使用它们的每个集成都需要单独更新到新凭据。设置和更新凭据的这种主要是手动的方法意味着基本身份验证不适合大规模地用于集成。

了解 API 密钥认证方法

API 密钥是用于标识和身份验证的单个字符串，特别是在涉及使用 API (应用程序编程接口)的集成时。基于 API 键的授权通常称为基于令牌的授权，在现代 SaaS 应用程序中很常见。

要使用 API 密钥设置认证，应用程序创建一个密钥供您与集成一起使用。您通常可以在“设置”或“配置文件”菜单下的应用程序中生成一个键。

HTTP 请求中的 API 密钥示例如下所示:

curl <https://example.com> \\
  --header "Authorization: Bearer mF_9.B5f-4.1JqM"

您可能注意到，该模式与我们用于基本身份验证的模式非常相似，具有 Authorization 标头，但是这次使用了 Bearer { token }值。

API 键也可以作为某些 API 的参数传入:

curl <https://example.com?token=mF_9.B5f-4.1JqM>

或者，您甚至可以使用 API 键的自定义头:

curl <https://example.com> \\
  --header "x-acme-api-key: mF_9.B5f-4.1JqM"

为什么 SaaS 团队使用 API 密钥认证方法进行集成

尽管 API 身份验证方法需要比基本身份验证更多的设置，但它们并不难实现。通常，生成的应用程序将 API 键(或这些键的散列)存储在一个表中，并将这些键与相应的用户匹配。

使用 API 密钥的一个好处是可以设置权限(授权)的范围，这与基本授权不同。您可以设置单个令牌以对特定资源进行只读访问，同时设置另一个令牌以访问通过 API 可用的所有资源。因此，您可以为每个集成使用不同的令牌，并且用户是否更改密码并不重要—— API 密钥仍然映射到该用户名。如果一个集成不再需要访问 API，您可以从应用程序中删除/禁用相应的 API 密钥。

如果您使用的是嵌入式集成平台(也称为嵌入式 iPaaS) ，那么 API 键是与应用程序集成的理想选择。

使用 API 密钥认证方法进行集成时需要考虑的事项

用户需要将 API 密钥从一个应用程序复制粘贴到另一个应用程序。这个手动步骤不会花费太多时间，但是当数据没有被正确剪切和粘贴时，它可能会导致问题。另一个缺点是 API 密钥通常不会过期。因此，有人可能会破坏一个 API 密钥，这个密钥将继续工作，直到有人意识到并进入源应用程序禁用/删除它。

理解 OAuth 2.0方法

OAuth 2.0无处不在。毫无疑问，你自己也在很多应用程序中使用过它。一般来说，它的设置是让你点击应用程序 A 中的一个按钮，然后应用程序 A 将你发送到应用程序 B 询问你是否希望与应用程序 A 共享一些东西(电子邮件等)。您单击按钮以同意此数据共享，应用程序 A 被授予代表您的应用程序 B 的权限。

虽然表面上看起来非常简单，但复杂性是在幕后操作的:

为什么 SaaS 团队使用 OAuth 2.0方法进行集成

OAuth 2.0最强大的特性之一是授权(权限)可以很容易地限定到所需的特定访问: 对帐户的读访问、对联系人的读/写访问等。每个集成都可以使用不同的访问令牌，用户是否更改密码并不重要; OAuth 访问令牌仍然可以工作。

撤消刷新令牌也很简单，从而禁用用户生成新访问令牌的能力。与此同时，如果访问令牌以某种方式被破坏，它通常会很快过期并限制可能造成的损害。

使用 OAuth 的用户体验基本上不费吹灰之力，因为用户不需要输入任何数据，比如凭证或 API 密钥。相反，用户只需要批准应用程序之间的授权请求。

虽然 OAuth 2.0非常适合使用嵌入式集成平台(嵌入式 iPaaS)构建与第三方应用的集成，但它也是最强大、最安全的身份验证方法ーー无论你为集成做什么。

使用 OAuth 2.0方法进行集成时需要考虑的事项

使用 OAuth 2.0比使用基本身份验证或 API 密钥都有更多的开销。您需要构建基础设施来跟踪使用 OAuth 2.0的任何应用程序的客户端 ID 和客户端机密。此外，还需要设置应用程序/API 来创建一个回调 URL，该 URL 将授权代码作为输入，并将其交换为访问令牌和刷新令牌(如果适用)。

最后，您还需要构建一些东西来定期刷新访问令牌。这可能是一个 cron 作业，AWS Lambda 等。

如果您正在构建应用程序和第三方应用程序之间的自定义内部集成，那么使用 OAuth 2.0可能是最有意义的，因为它提供了用户体验和内置保护。如果出于某种原因不能采用这种方法，那么使用 API 密钥应该仍然可以提供良好的用户体验和安全性。基本认证虽然有其用例，但对于大多数现代 SaaS 应用程序而言并非最佳选择。

但是，如果你使用嵌入式 iPaaS 来创建、部署和维护应用程序的本地集成，那么这个平台应该带有内置的连接器，可以连接到许多应用程序，这些应用程序可以处理你的大部分身份验证需求，而不需要你编写额外的代码。您甚至可以设置您的应用程序，以便创建一个 API 密钥，然后当客户激活集成时，将该密钥提供给集成配置中的客户。

无论您是在内部构建集成还是使用嵌入式集成平台，对用户身份验证方法的基本理解将帮助您执行集成计划。