security - 用于服务器到服务器 API 安全的 OAuth

Question

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

许多人认为，OAuth 是最佳选择。根据是否希望不使用安全套接字协议(protocol)，分别选择 OAuth 1.0A 或 OAuth 2.0。

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

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

这仍然留下授权，OAuth 通过交换 token 来管理授权。但为什么这么复杂呢？例如，我可以为所有服务器(私有(private)消费者)提供全局唯一的用户名和 secret ，以便每个“请求”都使用 secret 、用户名和请求参数的一些哈希值进行“签名”吗？

据我所知，这意味着授权和身份验证。身份验证是通过哈希确认来管理的，而授权是被禁止的，因为最重要的是，每个服务器对其自己的资源拥有相同的权限。

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

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

Answer 1

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

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

如果你看看 OAuth 的作用，你会发现它基本上为每种要授予的访问权限创建了一个新的唯一共享 secret (称为 token ，但如果你愿意，也可以将其称为密码)。该唯一 secret 由 S2 生成，但从 S1 传递到 S3，并且可以被 S3 用作访问 S2 的密码。 S2 正在“控制”访问。 OAuth 所做的唯一一件事就是将 token 获取到 S3。这样就无需设置密码并在系统之间手动携带密码。

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

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

一旦您在服务器之间建立了基本的信任关系，您就可以签署请求或签署响应(用于不可否认的目的)。

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

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