对于服务器到服务器的通信，OAuth 是否比 Basic Auth 更安​​全

Question

对于服务器到服务器的对话，OAuth 是否比通过 HTTPS 的基本身份验证更安全？

我的意思是，如果我想使用 OAuth 从服务器 A 向服务器 B 发出一些 API 请求，我必须在服务器 A 上存储一些身份验证数据（密钥、秘密等）。然后使用这些身份验证数据，我可以拥有一个令牌并使用此令牌向服务器 B 发出请求。稍后使用相同的身份验证数据，我将拥有一个令牌密钥，并且能够使用这个新令牌发出请求。

使用基本身份验证，我在服务器 A 上有一些身份验证数据（用户、密码）。我现在和以后都可以在 B 上使用这些数据执行请求。

现在假设身份验证数据被发现，因为服务器 A .conf 上有一个包含身份验证数据的文件，并且该文件被盗。在这两种情况下（OAuth 和 Basic Auth），这都太糟糕了，并且使用 OAuth 而不是 Basic Auth 没有任何好处。一个真实案例的例子：我前几天刚刚创建了一个twitter bot（与OAuth连接），如果发现配置信息，帐户被盗，attaquant现在和将来都可以使用这个bot。

那么，在使用 Oauth 而不是 Basic Auth 进行服务器到服务器请求（使用 HTTPS）时，我不知道（或者我可能误解了什么）还有另一个原因吗？

Answer 1

如果服务器本身被破坏，它们看起来确实相似，但如果您认为破坏发生在通信通道中，则存在细微差别。

对于基本身份验证，每个请求中始终包含完整的凭据，而对于 OAuth，它是每个请求中包含的访问令牌。乍一看，这似乎相同，但令牌确实具有一些有趣的特征：

• 它们可以有一个相关的过期时间，以减少单个泄漏的影响。
• 它们的范围可以缩小，即应用程序具有写访问权限，但由于它的大多数请求只需要读访问权限，因此它会请求它在大多数请求中使用的只读访问令牌；这再次将泄漏的影响降至最低。

另一个有趣的部分是，大多数违规行为可能发生在通信通道中，而不是服务器本身，因此这似乎很重要。

但也有一些缺点，如果您需要立即撤销功能，不记名令牌需要一些额外的复杂性。