情况：
有一个系统细分为以下上下文（使用战略 DDD 模式）：
- 识别和访问的上下文（识别和授权）
- 某些对象的注册上下文
- 轮询上下文（用于获取有关已注册对象的信息）
基于指定的任务分工，我决定构建一个基于微服务架构的系统。
一个任务：
系统安全
问题：
基于上述背景，出现了如何维护这样一个系统的安全性的问题。在这种情况下，事实证明所有服务的标识和授权都位于一个节点中。在我看来，我的观点是：
- 这是不安全的——这个节点的故障会降低整个系统的安全性；
- 微服务变得不那么自主；
谁有搭建微服务架构的经验，请告诉我：这种情况下如何保证安全性更好？
要开始，请查看一篇不错的四部分介绍性文章：
另外，阅读有关十二因素应用程序的信息：
我还推荐 Robert Martin 的“Clean Architecture”，即第 27 章，作者在其中写道，如果可能的话，微服务器代码组织的问题应该推迟到以后。微服务的时尚会过去，但代码可能会保留，所以它就是这样。
关于你的具体问题。你把你的微服务隐藏在所谓的网关（gateway）后面，它执行授权、负载均衡和链接微服务的功能。通常，解决方案的结构是这样组织的，一个网关对应一个客户端应用程序——一个用于 Web 客户端，另一个用于移动客户端。
因此，您开发了一个网关 - 本质上是相同的微服务 - 可从外部使用，并隐藏两个具有业务逻辑的微服务。单独设置认证服务。您可以使用可以使用 OAuth2 对用户进行身份验证的外部服务，例如 Google 或 Facebook。对于 .NET，有一个名为 IdentityServer 的半工厂解决方案。
如果您担心可靠性，您可以将验证器的两三四份副本隐藏在平衡器后面。如果您担心数据中心会出现故障，请在不同的数据中心安装带有身份验证器的平衡器，并通过 Round robin DNS 分发请求。在实践中，这已经是多余的——当涉及到大型已完成项目时，需要做出这样的决定。
验证器会给你
access_token，可能在 JWT 标准中。处理 HTTP 请求标头的网关将从Authorization标头中提取此令牌，验证签名，并从那里获取用户 ID。在微服务内部，已经传递了用户 ID。相信用户是正确的，因为签名在统计上是不可能伪造的。
带有访问令牌 (access token) 和刷新令牌 (refresh token) 的方案已经很好地证明了自己，在 OAuth2 标准中进行了描述，并且得到了工具性支持。假设同一个 IdentityServer 可以提供现成的令牌。