我有两个企业服务器需要以安全的方式进行通信，并且正在使用SSL（使用客户端/服务器证书来验证双方）与使用OAuth 2.0（可选地使用MAC令牌或JWT令牌）的双腿身份验证进行比较 .
从历史上看，OAuth似乎是为了完全不同的目的而创建的（三方案例，用户允许服务访问某些地方的某些数据），虽然两条腿现在已集成到OAuth 2.0规范中，看到两条腿的OAuth 2.0似乎没有提供超过SSL的额外保护 .
我能想到的唯一一点是OAuth可能比SSL更容易配置，并且容易犯错误，例如接受可能危及安全性的错误SSL证书 . 但是我不确定这是否足以与OAuth一起使用 .
请注意，我提到这些是单独的选项，但我认为使用OAuth可能需要在HTTPS / SSL之上使用它，因此两者都将被使用 .
使用OAuth 2.0双管方案进行服务器到服务器通信（没有用户参与）有什么真正的优势吗？
注意：我确实找到了一个有点类似的帖子here，但这已经很老了，但我不觉得在这件事上得到了满意的答案 .
2 回答
我会回复这个评论：
总结：我不打扰两者兼顾 .
细节：双腿OAUTH仅与消费者秘密一样安全 . 类似地，相互身份验证SSL仅与私钥一样安全 . 我假设您将这些存储在每台服务器上的某个加密存储中 . 由于两者都存储在同一个地方，因此我发现添加OAUTH没有额外的安全性 .
现在，如果您正在考虑在相互身份验证SSL和标准SSL之间进行身份验证，那么OAUTH可能会在那里发挥作用 . 我会选择那些选项似乎更容易 . 因此，如果您有一个OAUTH系统并且可以轻松地向其添加服务器身份验证，那么可能就是这样 . 否则，只需使用相互身份验证SSL . 配置起来往往有点麻烦，但一旦设置就能很好地运行 .
如果您已经知道这一点，请道歉，但在您的帖子中并不清楚 .
OAuth和SSL \ TLS是OSI模型的两个独立层 . OAuth用于身份验证，在第7层中位居第一，而SSL \ TLS用于第4层中的传输安全性 . 很容易将SSL与客户端证书混淆，因为它们都使用PKI .
您对OAuth的理解是正确的...它用于授权个人而非组织\服务器 . 两条腿OAuth是一个包含各种替代OAuth流的术语，所有这些都不符合标准 .
在我看来，您希望使用客户端证书来保护您的服务器 - 服务器通信...所有真正需要的是单个x509证书，可以用作SSL（传输安全性）和客户端证书（授权）;虽然使用2个证书是常态 .