这是一个有趣的话题，有几件事需要考虑。首先，我们需要从 API 提供者那里得到它，而不仅仅是消费者。

谁？

主要考虑因素是身份验证与“身份”和权限。复习：

• 身份=谁说你是谁
• 身份验证 = 你的真实身份
• 权限 = 你能做什么

查看这篇文章以获取有关 API ID 和权限的更多详细信息。

虽然在这种情况下，权限可能是隐式的（通过身份验证，您可以使用 API），但请考虑一下：作为 API 提供者提供的服务具有支付所需的敏感级别，我想知道消费者就是他们所说的那个人。

传递 API 密钥仅确认您拥有 API 密钥：并不能证明您有权访问 API。

现在，拥有 OAuth 访问令牌最初可能被视为相同，但是 OAuth RFC声明

授权服务器必须尽可能对客户端进行身份验证。

正如您所说，OAuth 通过提供刷新令牌以及注册的重定向 URI 来实现这一点。它还为所有初始和重新身份验证请求建议一个最小范围的令牌。

这为 API 提供者提供了更多的控制权、更多的可见性，从而更加确信他们的 API 没有受到损害。

OAuth 还可以很好地处理权限。如果支付网关公司决定扩展身份验证以要求 GET 和 POST 的权限，那么与您必须尝试将密钥绑定到权限相比，这将更少工作且更安全。

接触

次要但相关的考虑是如果 API 密钥被公开该怎么办。

我知道我希望能够信任密钥，但它可能已被破坏。因此，我还将客户端 IP 列入白名单... IP 可以更改，具体取决于配置，并且它们也可能被欺骗...我如何知道密钥是否被恶意使用？

如果 API 密钥在泄露后重新发布，那么一旦知道初始密钥，就可以更容易地确定可能的新密钥。这意味着提供者密钥生成算法可能也需要调整。

如果您获得了一个以某种方式暴露的访问令牌，那么一旦刷新，未经授权的用户应该无法获得重新授权。我可以记录他们记录这个错误的请求，并与消费者一起诊断根本原因。

概括

API 密钥只是用来作为 ID 的一种形式。因此，它们在作为主要安全措施实施时基本上被滥用。

如果需要对 API 使用者进行身份验证 - 例如您需要验证 API 的调用者并根据该验证提供对某些资源的访问权限 - OAuth 是更好的选择。

希望这可以帮助！

注意：为了争论，我假设没有人对您的内部服务或网络具有 root 访问权限，并且所有的有线通信都是通过 HTTPS 进行的。

API 密钥/客户端密钥对于服务到服务的通信更有意义，这似乎是我收集到的场景（您的后端到他们的 API 服务）。

话虽如此，OAuth 2 有一个客户端凭据授予流程，它可以执行某种基于 API 密钥/客户端机密/证书的身份验证 - 请与您的第三方提供商核实他们是否支持它。

通常 OAuth 2 与授权代码授权流程相关联，当用户代理是浏览器时这很好，因为这是它的设计目的，但不适合服务到服务。

是的，这是真的，它可能会发生。重放攻击很常见，但有一些方法可以非常安全地实施它。您的服务器绝对应该使用 ip 监控，这意味着一旦发出令牌，它将只允许特定的 IP，但这并不能解决问题，因为妥协可能来自内部。第二种方法是最小化到期时间，从而缩小暴露风险。最后，总是有 WebSockets ......它通常同步速度足够快，可以为每个请求发出新的令牌，这消除了大部分风险，因为它用于商业用途，在只能访问 x 端口的自己的专用 Vlan 上使用它。...等等等等

归根结底，您可以随心所欲地对其进行防弹，但您仍然无法在 MITM 攻击中幸存下来，尤其是当您的计算机上的根证书遭到破坏时。