用于服务器到服务器 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 是否安全，然后使用个性化哈希对每个请求进行签名，这意味着身份验证、授权并且也不需要维护状态/会话。

我可以理解，符合标准对于编写代码以使用服务的开发人员以及一般的 Web 文化都有好处，因此遵守 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 提供对 S2 的访问类型的选项，它提供给 S3。

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

Answer 2

您所描述的解决方案称为“使用客户端证书进行 HTTPS 通信”或“相互 SSL” - 服务器提供其证书和域，客户端提供证书以某种方式标识自己。适用于服务器到服务器的情况。

这种方法确实允许以安全和标准的方式对服务器/用户进行身份验证。接收传入请求的服务器将能够根据调用者提供的证书做出授权决定。调用服务器将需要向您的服务注册他们自己的证书或获取您的预定义证书才能调用您的服务。

此方法适用于您可以正确控制客户端证书分发或服务器接受以某种外部方式获得的证书的情况。如果您控制通信的两端（即保护您自己的多层系统组件之间的流量），那么这种方法是最简单的方法之一。