OAuth 2.0服务，用于服务身份验证和最佳实践

Question

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

1. 为Web用户创建身份验证流程;
2. 以同样的方式处理服务认证服务

简要说明下图可以描述我们拥有的主要组成部分：



对于用户身份验证我们希望使用OAuth2（隐式流），一般来说，它看起来或多或少都很清晰。

有关服务授权服务的问题是否可以使用OAuth2授权代码流程？

数据中心1内部存在的主要问题是大量的后端服务，这就是为什么它会很好，因为服务会像用户一样在类似的权限模型上工作（至少某些功能可能被收回）

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

Answer 1

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

虽然被广泛采用，但OAuth 2.0＆＃34;身份验证框架＆＃34;留下许多细节可供解释 - 这通常会导致实施的安全漏洞。 点击此处查看OAuth 2.0中最常见的10个实施漏洞：http://blog.intothesymmetry.com/2015/12/top-10-oauth-2-implementation.html

因此，实际的最佳做法是使用OpenID Connect，一种类似的协议（构建于OAuth 2.0之上），定义良好，可以缓解OAuth 2.0的大部分缺点。

OpenID Connect是对最终用户（主要是网络）进行身份验证的最佳做法。

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

• ＆＃34;对学习者＆＃34;实施：在适当的网络安全性时清除HTTP（例如，配置良好的VPC，因此不太可能从互联网访问任何这些服务器）
• ＆＃34; Safter＆＃34;实现：服务器到服务器基本身份验证（或类似）通过HTTPS，同时不时地旋转密钥。密钥应存储在安全存储中，例如Vault

在任何情况下，服务最好委派用户的请求（即通过提供user_id作为请求的一部分） - 并且将对该用户强制执行权限：

• 您可能不想允许一个用户访问其他用户的数据。
• 在任何情况下，通过链接到发起请求的用户，而不是某些通用＆＃34;系统用户＆＃34;来做更好的日志/审核。