用于服务器到服务器 API 安全性的 OAuth

Question

因此，过去几天我在互联网上搜索 API 安全“最佳实践”或技术，特别是从服务器到服务器（服务器到服务器）直接访问的 API。似乎有许多不同的意见，很难将它们整合为一个可行的想法。

许多人认为，OAuth 是必经之路。根据是否希望不使用安全套接字协议，可以分别选择 OAuth 1.0A 或 OAuth 2.0。

关于 OAuth，我的理解是 OAuth 1.0A 主要关注的是请求的数字标牌，而 OAuth 2.0 依赖底层 HTTPS 来保证完整性。那么我可以安全地做出以下假设吗？

假设：如果使用 HTTPS，则不需要使用 HMAC 或任何形式的数字签名来防止重放攻击、中间人攻击和保持完整性。

这仍然留下授权，OAuth 通过交换的令牌进行管理。但为什么这么复杂？例如，我是否可以为所有服务器（私人消费者）提供全局唯一的用户名和机密，以便每个“请求”都使用机密、用户名和请求参数的一些散列值进行“签名”？

据我所知，这意味着授权和身份验证。身份验证通过对哈希的确认进行管理，并且禁止授权，因为至关重要的是，每个服务器对自己的资源都具有相同的权限。

因此，在为服务器到服务器（或“两条腿”）通信设计 API 时，最好的方法是什么？简单地使用 HTTPS 是否安全，然后使用个性化散列对每个请求进行签名，这意味着身份验证、授权并且不需要维护状态/会话。

我可以理解，符合标准对开发人员编写代码以使用服务以及一般的网络文化是有益的，因此遵守 OAuth 的某些“子集”听起来很有吸引力；我只是不确定这里是否需要它。

Answer 1

假设您的系统 S1 已经与系统 S2 建立了信任关系。OAuth 的作用是提供一种机制，以便 S1 可以让 S3 访问 S2。也就是说，可以使用 S1 的部分权限，授予 S3 对 S2 进行操作的权限。它以 S1 可以控制的方式执行此操作。

问：“例如，我可以为所有服务器（私人消费者）提供全球唯一的用户名和机密吗？” 答：当然可以。如果您在要与之对话的每个系统上都有用户名和唯一密码，那么您就不需要 OpenID 或 OAuth。但这变得非常难以管理。OAuth 允许您在一个系统上拥有一个秘密，并根据这个秘密授权任意数量的其他系统。这是它存在的唯一原因。

如果您看一下 OAuth 的作用，是它基本上为要授予的每种访问权限创建了一个新的唯一共享密钥（称为令牌，但如果您愿意，也可以将其称为密码）。该唯一秘密由 S2 生成，但从 S1 传递到 S3，并可用作 S3 访问 S2 的密码。S2 正在“控制”访问。OAuth 所做的唯一一件事就是将令牌发送到 S3。这消除了设置密码和在系统之间手动携带密码的需要。

当您谈论“两条腿”通信时，问题是：共享秘密是如何在它们之间建立的？如果您手动（即物理携带）并使用密码设置两个系统，那么您就不需要 OAuth。但是如果你有很多系统，那就很麻烦了。N 个系统需要 (N*(N-1)/2) 个密码。

通常，您想要做的是让一台服务器充当“身份验证服务器”，并且每台服务器都与之建立信任关系。然后，您使用 OAuth 来授权任意两个其他服务器之间的任何交互。这就是复杂性的全部意义所在。

一旦您在服务器之间建立了基本的信任关系，您就可以在该签名请求或签名响应之上（出于不可否认的目的）。

在设计服务时，您需要考虑可能授予访问权限的方式。例如，您是否想要仅限 7 天的限时访问？您想提供“只读”访问权限吗？这将为 S1 提供有关它为 S3 提供的对 S2 的访问类型的选项。

举个具体的例子来说明：雪很好，你想去滑雪。滑雪场是开放的，但你所有的钱都在银行里。你要做的，是授权滑雪场从你的银行账户中提取资金。你不想把所有的钱都花在滑雪场上。您不信任他们的完整密码。因此，您首先联系银行，并安排“许可”以提取特定金额的资金。这由令牌表示。然后您将该令牌传递给滑雪区。使用该令牌，滑雪场能够提取指定数量的资金。始终负责保护您的资金，而银行定义了您可以设置权限的交易类型。OAuth 只是一种安全地传递令牌的标准方式。