因此，过去几天我在网上搜索了API安全性“最佳实践”或技术，特别是对于从服务器到服务器（服务器到服务器）的直接访问的API。似乎有很多不同的意见，很难将它们合并成一个可行的想法。
根据许多人的意见，OAuth是要走的路。根据是否希望不使用安全套接字协议，选择分别是OAuth 1.0A或OAuth 2.0。
关于OAuth，我的理解是OAuth 1.0A主要关注的是请求的数字标牌，而OAuth 2.0依赖底层HTTPS来保证完整性。我可以安全地做出以下假设吗？
假设：如果使用HTTPS，则不需要使用HMAC或任何形式的数字签名来防止重放攻击，中间人攻击并保持完整性。
这仍然会留下授权，OAuth通过交换的令牌管理授权。但为什么它如此复杂？例如，我可以为所有服务器（私人消费者）提供全球唯一的用户名和秘密，以便每个“请求”都使用秘密，用户名和请求参数的一些散列进行“签名”吗？
据我所知，这意味着授权和身份验证。通过确认哈希来管理身份验证，并且禁止授权，因为严格来说，每个服务器都具有与其自己的资源相同的权限。
因此，在设计严格用于服务器到服务器（或“双腿”）通信的API时，最好的方法是什么？简单地使用HTTPS是安全的，然后使用个性化哈希对每个请求进行签名，这意味着身份验证，授权以及不需要维护状态/会话。
我可以理解，符合标准是开发人员编写代码来使用服务和一般的网络文化的好处，因此对OAuth的某些“子集”的吸引力听起来很有吸引力;我不确定这是否需要。
答案 0 :(得分：4)
假设您的系统S1已与系统S2建立了信任关系。 OAuth所做的是提供一种机制，以便S1可以为S3提供S3访问权限。也就是说，使用S1的某些部分权限，S3可以被授予对S2进行操作的许可。它以S1控制的方式执行此操作。
问：“例如，我可以为所有服务器（私人消费者）提供全球唯一的用户名和秘密” 答：当然可以这样做。如果您在要与之交谈的每个系统上都有用户名和唯一密码，那么您就不需要OpenID或OAuth。但这变得非常难以管理。 OAuth允许您在一个系统上拥有一个秘密，并根据一个秘密授权任意数量的其他系统。这是它存在的唯一原因。
如果你看看OAuth做了什么，它是否基本上会产生一个新的唯一共享秘密（称为令牌，但如果你愿意，你也可以称之为密码），以便给出每种类型的访问权限。该唯一秘密由S2生成，但是从S1传递到S3，并且可以由S3用作密码以访问S2。是S2“控制”访问。 OAuth唯一能做的就是将令牌送到S3。这消除了设置密码的需要，并在系统之间手动携带密码。
当你谈到“两条腿”的通信时，问题是：它们之间是如何建立共享秘密的？如果您手动（即物理携带）并使用密码设置两个系统，则您不需要OAuth。但是如果你有很多系统，那就很麻烦了。 N个系统需要（N *（N-1）/ 2）个密码。
通常，您要做的是让一台服务器充当“身份验证服务器”，并且每台服务器都与之建立信任关系。然后，您使用OAuth授权任何其他两个服务器之间的任何交互。这就是复杂性的全部内容。
一旦您拥有服务器之间的基本信任关系，您就可以在该签名请求或签名响应之上（出于不可否认的目的）。
在设计服务时，您需要考虑可以提供访问的方式。例如，您是否希望限时访问仅在7天内有效？您想要“只读”访问吗？这将为S3提供对S2的访问类型的S1选项。
让我用一个具体的例子来说明：雪是好的，你想去滑雪。滑雪场是开放的，但你所有的钱都在银行里。你想要做的是授权滑雪场从你的银行账户中提取资金。你不想把所有的钱都捐给滑雪场。您不完全信任他们的密码。因此，您首先联系银行，并安排“许可”以提取特定金额。这由一个标记表示。然后，您将该令牌传递到滑雪区。使用该令牌，滑雪场可以提取指定数量的资金。始终负责保护您的资金，银行负责定义您可以设置权限的交易种类。 OAuth只是安全传递令牌的标准方法。
答案 1 :(得分：1)
您所描述的称为“使用客户端证书进行HTTPS通信”或“相互SSL”的解决方案 - 服务器将其证书与域和客户端呈现证书以某种方式识别自身。适用于服务器到服务器的情况。
这种方法确实允许以安全和标准的方式验证服务器/用户。接收传入请求的服务器将能够根据调用者提供的证书做出授权决策。调用服务器需要在服务中注册自己的证书，或者获取预定义的证书来调用您的服务。
此方法适用于可以正确控制客户端证书分发或服务器接受以某种外部方式获取的证书的情况。如果您控制通信的两端（即保护您自己的多层系统的组件之间的流量），那么这种方法是最简单的方法之一。