API网关与微服务endpoint中的授权
我正在尝试构建一个微服务架构。我已经了解了API网关的一些好处，比如：负载平衡、调用多个微服务并聚合结果、缓存管理等。所以我决定将它包含在我的系统中。
我的问题是，我应该在网关层还是在每个微服务endpoint单独实现授权？例如，在网关上验证用户，并以解密的形式将用户声明传递给每个服务调用的授权逻辑。
在调用每个服务之前授权一些聚合似乎是有意义的，并且节省了处理时间。然而，授权逻辑实际上是单个服务的关注点。
你有什么建议？
共有2个答案
可以使用API网关模式/ API网关。然后，您还可以卸载微服务的身份验证/授权责任。对于调用服务的用户或开发人员来说，这很容易。API GW甚至支持外部/内部GW。它可以支持基于角色的权限。APIM。
当您拥有API /MS GW时，您将获得以下优势:
- API网关是任何微服务调用的单一入口点
- 它可以作为代理服务将请求路由到相关的微服务
- 它可以汇总结果，然后发送回消费者
- 此解决方案可以为每种特定类型的客户端创建细粒度API
- 它还可以转换协议请求和响应
每个微服务终结点。在 API 网关中实现授权会使您的系统僵化。如果在以后的任何阶段，您必须分离授权逻辑（例如，内部用户、外部用户、打开 api）。这将很难合并。授权应在每个 API 级别进行。
-
让我们说，我正在开发博客平台，用户可以注册帐户，支付订阅和创建自己的博客。平台由以下微服务组成： 帐户-服务 auth-service 订阅-服务 博客-服务 API-网关 我正在考虑实现api-gw模式，其中除了api-gw之外的所有微服务都将部署到专用网络中（在那里，它们将能够通过message broker直接以同步或异步方式相互通信），并且它们将只通过api-gw公开可用。 null 我的
-
我有一个多租户项目，它将调用多个微服务来执行特定任务。 我希望微服务从发送的请求中了解要使用哪个DB，因为每个租户都将使用微服务，但是，租户将拥有自己的DB。我有另一个解决方案，它有一个处理API密钥管理的Web项目。 比方说，API密钥管理位于域:portal.example.com 当 tenant.example.com 在 microservice.example.com 调用微服务时，我
-
我最近读了不少关于微服务的文章，尤其是关于AuthN和Authz的文章。在很大程度上，这一切都很有意义，我可以看到这一切应该如何工作。 （注意--现在我只实现了客户端凭据授予和资源所有者密码凭据授予，因为我只是想看看它是如何工作的，而且用curl调用它们更容易。但我不知道这有什么不同）
-
在微服务架构中，建议： > 客户端应用程序到API网关的通信应该是同步的（就像http上的REST一样）。 API网关到微服务的通信也应该是同步的 但是服务到服务的通信应该是异步的。 您应该尽可能遵循的另一个规则是，只使用内部服务之间的异步消息传递，只使用从客户端应用程序到前端服务（API网关加上第一级微服务）的同步通信（如HTTP）。 现在，如果我理解正确的话，当用户向API gateway请求
-
我们能在Spring Cloud API网关和没有服务发现的情况下生存吗？
-
到目前为止，我还没有找到使用Blazor服务器（不是WebAssembly）和API网关和微服务的指导。讨论这些Blazor以及API网关和微服务的文章总是提到Blazor WebAssembly（Wasm）。（是不是假设Blazor Server应用程序不会使用微服务？此外，值得一提的是，选择Blazor服务器而不是Blazor WebAssembly的原因是为了更好地保护知识产权。） 无论如何