与 OAuth2 相比，机器对机器通信中的基本授权是否良好

Question

简介

所以在我的开发团队中，我们需要两个基于服务器的应用程序，一个位于我的公司架构中，我们称之为公司服务器（即 OAuth2 术语中的资源和授权服务器），第二个位于客户架构让我们称之为客户服务器（即客户端和资源所有者）。客户服务器正在从公司服务器加载数据，因此我的公司服务器需要以某种方式对其进行身份验证。

我的团队决定在单个单体应用程序中应用带有授权和资源服务器的 OAuth2 标准，甚至没有考虑好处。当然，与存储在标头中的简单常量键相比，这将花费更多时间来实现。所以我想知道这个解决方案有什么好处。

我知道基本身份验证在每个请求中都需要user:password base64 编码，但客户服务器是单个用户，因此令牌实际上是存储在标头中的常量密钥，我将使用该术语来简化。

参数 - 微服务

在M2M（机器对机器）通信according to this article中，客户服务器应通过提供client_id和client_secret从授权服务器获取令牌，然后您可以与多个资源服务器一起使用。我看到的第一个论点是 OAuth2 模式允许我们使用多个资源服务器，而无需在每个资源服务器中额外重新实现授权（因为令牌是 JWT 或资源服务器正在检查令牌与授权），但在我们的例子中，我们只有一个单一的公司服务器负责成为资源和授权，所以我认为没有任何好处。

论证 - 中间人保护

使用 OAuth2 的另一个论点是，如果有人截获令牌，可以防止中间人攻击。授权服务器可以使令牌失效（直接在存储中或在签名 JWT 的情况下在较短的到期时间内）并防止使用受损的令牌。但是……

1. 服务器之间的连接受 SSL 保护
2. 无法像在基于 Web 或基于移动的应用程序中那样从存储中窃取令牌，因为密钥位于服务器端本身。

总结

因此，在这种情况下，与在每个请求中使用常量密钥相比，我想不出使用 OAuth2 有什么安全优势。

Answer 1

安全主要是一个鸡蛋问题。你用加密密钥加密秘密，然后你又想我们如何以安全的方式处理加密密钥。不要在这里假设 TLS/SSL 是万无一失的。但核心目标始终是减少攻击面，让恶意用户更难破解系统。

即使没有“中间人”，当您在每次请求中发送密码时，接收方和发送方都会将密码保存在内存中。它为攻击者提供了更多获取密码的机会。一个简单的内存转储可以暴露密码。

对于令牌，您并不总是需要内存中的私钥来验证令牌签名。您可以在服务器端缓存有效令牌并简单地进行字符串匹配。或者您可以使用公钥私钥对。

因此，如果安全要求不够严格，不足以证明更安全的解决方案所需的开发工作是合理的，则可以不使用 OAuth2。但最好使用经过验证的最佳实践和解决方案。