带api网关的微服务授权模式
让我们说，我正在开发博客平台，用户可以注册帐户，支付订阅和创建自己的博客。平台由以下微服务组成：
- 帐户-服务
- auth-service
- 订阅-服务
- 博客-服务
- API-网关
我正在考虑实现api-gw模式，其中除了api-gw之外的所有微服务都将部署到专用网络中（在那里，它们将能够通过message broker直接以同步或异步方式相互通信），并且它们将只通过api-gw公开可用。
-
null
我的问题是关于授权和授权应该在哪里进行（或者更确切地说，不同方法的优点/缺点是什么）。让我们重点关注两个“endpoint”：
- fronten-api-gw::createblog()=>blog-service::createblog()
前端api-gw公开endpoint来创建一个新的blog，这个api调用被“转发”到blog-service：：createblog（）endpoint。假设用户已经通过身份验证（即，带有用户id的正确JWT随请求一起传递给api-gw）。
在案例A中，由于授权层的存在，每个微服务中的逻辑更加复杂。在有更多的API GW、用户角色等的情况下会变得更加复杂。但是API GW在这种情况下更简单，它只将请求转发给微服务。
在案例B中，每个微服务中的逻辑不那么复杂、简单和直接。但是，API GW中有更多的逻辑，因为它必须实现所有平台的授权（至少是这个API GW负责的部分）。也许将所有授权都放在一个地方，而不是分散在微服务中，也是一个优势？
另外，在案例B中，我认为单个微服务之间的耦合较少。
你们对这两种方法有什么看法/也许你们有其他的“想法”？
共有1个答案
在我的经验中，我发现案例A是最容易扩展/维护的。授权逻辑可能会与业务逻辑混在一起。
例如，假设您要授权/updateblog？id=52143方法。在网关中这样做必须知道，不仅该用户被授权，而且他们拥有特定的博客，或者他们有权更新委托给他们的博客。
将所有这些逻辑导出到网关是可能的，但很棘手，最终会感觉高度重复。当逻辑发生变化时，这变得更加痛苦，并在系统中产生级联。例如，假设您的/updateBlog授权现在有了“来宾更新者”。必须对/UpdateBlog服务和网关进行同步更新，这更棘手，也更昂贵。
-
我正在尝试构建一个微服务架构。我已经了解了API网关的一些好处，比如：负载平衡、调用多个微服务并聚合结果、缓存管理等。所以我决定将它包含在我的系统中。 我的问题是，我应该在网关层还是在每个微服务endpoint单独实现授权？例如，在网关上验证用户，并以解密的形式将用户声明传递给每个服务调用的授权逻辑。 在调用每个服务之前授权一些聚合似乎是有意义的，并且节省了处理时间。然而，授权逻辑实际上是单个服务
-
我有一个多租户项目，它将调用多个微服务来执行特定任务。 我希望微服务从发送的请求中了解要使用哪个DB，因为每个租户都将使用微服务，但是，租户将拥有自己的DB。我有另一个解决方案，它有一个处理API密钥管理的Web项目。 比方说，API密钥管理位于域:portal.example.com 当 tenant.example.com 在 microservice.example.com 调用微服务时，我
-
我有两个Spring启动应用程序。后端部分-可以访问数据库，它用作Rest API和管理面板。前端部分-使用Rest API为客户端显示信息。 因此，我对客户端（前端）的配置安全性有问题，对管理面板也有问题，授权是通过会话实现的。以前，客户端部分的授权是通过JWT令牌实现的，但我不太明白如何为每个客户端存储令牌，并在向Rest API发送请求时使用它。 这是我的安全配置： 那么，可以使用JWT令牌
-
null
-
我试图在AWS API网关上使用自定义授权器（它验证jwt）来保护lambda函数。我还想将任何传递到我的lambda函数中，因此我想保持我的集成请求是lambda代理。 自定义授权程序已设置、测试并开始工作 问题： 谢谢你！
-
我们能在Spring Cloud API网关和没有服务发现的情况下生存吗？