Oauth 2.0 如何在microservices体系结构中使用第三方IDP实现OpenID Connect身份验证

在过去的10多天里，我阅读了一篇关于理解OAuth2和OpenID Connect的文章，看了所有我能找到的内容，结果发现很多人对实现有不同意见，这让我很困惑

据我所知，我找到的所有文章和示例都假设你想访问谷歌日历、个人资料信息或电子邮件（如果你使用谷歌登录），但我不需要访问我自己的API以外的内容-我只想使用谷歌、脸书等进行登录，并且获得一个id，我可以在我自己的数据库中链接到我的用户——仅此而已

我将尝试说明我的用例，并以此为例

图上有一个注释：身份验证服务可能内置在API网关中——对于这个例子来说，这并不重要，因为这不是关于“在哪里做”，而是关于“如何以最佳方式做”，对于像我这样的架构，它用于我自己的API/微服务，而不是访问Google，Facebook等外部API

如果你能理解我试图用上面的图表来说明什么，请告诉我我是否误解了这一点

您在这里看到的这种体系结构的最基本要求是：

• 用户可以通过Google、Facebook等登录
• 所有micro服务都将使用相同的登录名
• OpenId用户将在数据库中拥有一个链接帐户
• 用户访问在我自己的数据库中根据组、角色和权限定义

我不打算在用户经过身份验证和登录后使用外部API。无需访问用户日历、电子邮件等。因此，我只需要验证部分，无需其他（成功登录的证明）。所有用户访问权限都在我自己的数据库中定义

所以我想到了几个基本问题

• 首先，OpenID Connect是不是仅仅用于身份验证的正确工具（我不需要授权，因为除了通过身份验证获取ID之外，我不需要对google/facebook API进行读/写访问）
• 人们通常不同意是否使用ID或访问令牌来访问自己的API。据我所知，ID令牌仅用于客户端（用户代理），访问令牌用于访问谷歌日历、电子邮件等。。。。OpenID提供程序的外部API。。。但由于我只访问自己的API，我是否需要访问令牌或ID令牌？保护自己的API的正确方法是什么

如果ID令牌真的只用于客户端，那么它可以显示当前登录的用户，而不必访问数据库，我对它的使用率为0，因为我可能会从数据库查询用户，并将其存储在我的react前端应用程序的redux中

困境：是否将用户详细信息、组、角色和权限存储在JWT中以供API授权？

• 通过仅将用户标识符存储在令牌中，这意味着我始终允许具有有效令牌的经过身份验证的用户在授权之前调用端点，然后根据db查询结果和我自己数据库中的权限确定访问权限
• 通过在JWT中存储更多关于用户的数据，这意味着在某些情况下，我能够在点击API之前进行授权/访问（组、角色、权限）检查——只有在登录时发布的JWT中存储了用户信息、组、角色和权限时才可能。在某些情况下，由于CMS内容访问权限处于每个节点级别，因此不可能实现。但这仍然意味着更好的表现

正如图中所示，我通过网关发送所有API请求，网关将（自身或使用身份验证服务）将不透明访问令牌转换为带有标识符的JWT，因此我可以在图形数据库中识别用户，然后验证用户是否具有所需的组，角色和权限-不是来自外部API，而是来自我自己的数据库，如图中所示

这似乎需要对每个请求进行大量的工作，即使服务可以共享JWT，以防多个服务需要相互交叉调用

总是在数据库中查找用户及其权限的优点自然是，当用户访问级别更改时，他会立即被拒绝/授予访问权限，并且访问将始终保持同步。如果我将用户详细信息、组、角色和权限存储在JWT中，并将其保存在客户端localstorage中，我想这可能会带来安全问题，并且很难更新JWT中的用户信息、组、角色和权限

在JWT中存储用户访问级别和信息的一大优势当然是，在许多情况下，我可以阻止用户调用某些API，而不必在db查找后确定访问权限

因此，整个令牌转换意味着以性能为代价提高安全性，但这是普遍推荐的，值得吗？或者在JWT中存储用户信息和组、角色、权限是否足够安全

如果是，我是否将自己数据库中的所有信息存储在ID令牌、访问令牌或第三个令牌中？哪个令牌被发送到API，并根据用户在数据库中的权限确定是否应授予用户访问给定资源的权限？如果我不需要与ID提供者API交互，我真的需要访问令牌吗？或者，我是否将我的所有组、角色、权限存储并附加到OpenID connect发布的ID令牌（对我来说似乎不干净）中，然后调用API并使用它授权我自己的API端点，即使有人说永远不应该使用ID令牌访问API？或者我创建一个新的JWT来存储从我的数据库中获取的所有信息，用于决定用户是否可以访问给定的re