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

所以在过去的几天里，我在互联网上搜寻API安全“最佳实践”或技术，特别是从服务器到服务器（服务器到服务器）直接访问的API。似乎有很多不同的观点，很难把它们整合成一个可行的想法

据许多人说，OAuth是一条路要走。根据是否希望不使用安全套接字协议，可以分别选择OAuth 1.0A或OAuth 2.0

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

假设：如果使用HTTPS，则不需要使用HMAC或任何形式的数字签名来防止重放攻击，中间人攻击和保持完整性。 这仍然保留授权，OAuth通过交换的令牌管理授权。但为什么这么复杂呢？例如，我是否可以为所有服务器（私人消费者）提供全局唯一的用户名和机密，以便每个“请求”都使用机密、用户名和请求参数的散列进行“签名”

据我所知，这意味着授权和身份验证。身份验证是通过确认散列来管理的，而授权是被禁止的，因为关键是，每个服务器对自己的资源都具有相同的权限

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

---

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

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

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

---

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

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

问：“例如，我可以为所有服务器（私人用户）提供全局唯一的用户名和密码吗？” A:当然可以。如果您想与每个系统通话时都有用户名和唯一密码，那么就不需要OpenID或OAuth。但这变得很难管理。OAuth允许您在一个系统上拥有一个秘密，并基于该秘密授权任何数量的其他系统。这是它存在的唯一原因

如果您看看OAuth的功能，它基本上为每种访问提供了一个新的唯一共享秘密（称为令牌，但如果您愿意，也可以称为密码）。该唯一秘密由S2生成，但从S1传递到S3，S3可以将其用作访问S2的密码。是S2“控制”了访问。OAuth所做的唯一一件事就是将令牌获取到S3。这样就无需设置密码，也无需在系统之间手动携带密码

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

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

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

在设计服务时，您需要考虑提供访问权限的方式。例如，您是否希望只有7天的时间限制访问？是否要使“只读”访问可用？这将为S1提供对S2的访问类型的选项，而S2则提供给S3

让我用一个具体的例子来说明：雪是好的，你想去滑雪。滑雪场是开放的，但你所有的钱都在银行里。你要做的是授权滑雪场从你的银行账户中提取资金。你不想把所有的钱都给滑雪场。您不信任他们提供完整的密码。因此，你首先联系银行，并安排“许可”提取特定金额的资金。这由令牌表示。然后，你将该代币传递到滑雪区。使用该代币，滑雪区可以提取指定金额的资金。政府总是要负责