authentication - OAuth 2.0 服务到服务身份验证和最佳实践

Question

我必须处理这种类型的身份验证流程:

为 Web 用户创建身份验证流程；

以同样的方式处理服务到服务的身份验证

下图简要描述了我们将拥有的主要组件:



对于用户身份验证，我们希望使用 OAuth2(隐式流程)，通常它看起来或多或少清晰。

关于服务到服务授权的问题可以使用 OAuth2 授权代码流吗？

那里的主要问题是 datacenter1 内部将有大量后端服务，这就是为什么它会很好，因为服务将在与用户类似的权限模型上工作(至少某些功能可能会被收回)。

还有一个额外的问题:如果授权服务器位于 Datacenter1 内部或外部，此用例的一般建议是什么？

Answer 1

首先:OAuth 2.0 不是身份验证协议(protocol)，它是委托(delegate)访问协议(protocol)。这里明确说明:https://oauth.net/articles/authentication/

尽管被广泛采用，但 OAuth 2.0“身份验证框架”留下了许多可供解释的细节——这通常会导致实现的安全缺陷。
在此处查看 OAuth 2.0 中 10 个最常见的实现漏洞:http://blog.intothesymmetry.com/2015/12/top-10-oauth-2-implementation.html

因此，实际的最佳实践是使用 OpenID Connect，这是一种类似的协议(protocol)(建立在 OAuth 2.0 之上)，定义明确，可以缓解 OAuth 2.0 的大部分缺点。

OpenID Connect 是验证最终用户(主要是 Web)的最佳实践。

如果您想在数据中心内进行身份验证，使用的解决方案的种类会更广泛 - 但总的来说，我认为最常见的最佳实践是:

“更精简”的实现:在适当的网络安全性时清除 HTTP(例如，配置良好的 VPC，因此不太可能从 Internet 访问任何这些服务器)

“Safter”实现:通过 HTTPS 的服务器到服务器基本身份验证(或类似)，同时不时轮换 key 。 key 应存储在安全存储中，例如 Vault

在任何情况下，服务最好将请求委托(delegate)给用户(即通过提供 user_id 作为请求的一部分) - 并且将为该用户强制执行权限:

您可能不希望允许一个用户访问另一个用户的数据的错误。

在任何情况下，最好通过链接到发起请求的用户而不是一些通用的“系统用户”来完成日志/审计。