architecture - 带有 api 网关的微服务授权模式

Question

假设我正在开发博客平台，用户可以在其中注册帐户，支付订阅费用并创建自己的博客。平台由以下微服务组成:

账户服务

身份验证服务

订阅服务

博客服务

api网关

我正在考虑实现 api-gw 模式，其中除 api-gw 之外的所有微服务都将部署到专用网络(在那里它们将能够通过消息代理同步或异步直接相互通信)并且它们将仅通过api-gw。

API 将有两个客户端/消费者:

前端(针对客户)

cms(管理员)

因此，我想使用每个客户端单独的 api-gw 模式，所以实际上会有两个 api 网关，一个用于常规前端(frontent-api-gw)，一个用于 cms(cms-api-gw)，但两者都将使用相同的微服务。

我的问题是关于授权以及应该在哪里进行(或者更确切地说，不同方法的优缺点是什么)。让我们关注两个“端点”:

前端 api-gw::createBlog() => 博客服务::createBlog()

前端 api-gw 公开端点以创建新博客，并且此 api 调用“转发”到 blog-service::createBlog() 端点。假设用户已经通过身份验证(即带有用户 ID 的正确 JWT 与请求一起传递给 api-gw)。

必须进行的授权是确定具有此 id 的用户是否可以创建新博客。这可以通过调用订阅服务来检查用户是否已付费订阅来完成。主要问题是是否应该在 api-gw 端 (A) 或博客服务端 (B) 进行此授权:

cms-api-gw/前端-api-gw::listBlogs() => 博客服务::listBlogs()

类似的情况 - 是否应该将任何格式的 userContext/JWT 传递给每个单独的微服务，并且该微服务应该决定返回什么？还是个别微服务不应该知道 userContext(可能仅用于记录目的)，依赖 API GW 授权而只接收一些参数/参数？



我的想法:

在案例 A 中，每个单独的微服务中的逻辑由于授权层而更加复杂。如果有更多 API gws、用户角色等，可能会变得更复杂。
然而，在这种情况下，API GW 更简单，它只将请求转发给微服务。

在案例 B 中，每个单独的微服务中的逻辑不那么复杂，简单明了。然而，API GW 中有更多的逻辑，因为它必须为所有平台实现授权(至少对于这个 api gw 负责的部分)。也许将所有授权集中在一个地方而不是分散在微服务中也是一种优势？

同样，在情况 B 中，我认为各个微服务之间的耦合较少。

你们如何看待这两种方法/也许您还有其他“想法”？

Answer 1

根据我的经验，我发现案例 A 是最容易扩展/维护的。授权逻辑可能与业务逻辑混为一谈。

例如，假设您要授权/updateBlog?id=52143 方法。在网关中这样做必须知道不仅该用户已获得授权，而且他们拥有该特定博客，或者他们有权更新委派给他们的该博客。

将所有这些逻辑导出到您的网关是可能的，但很棘手，并且最终会让人感到高度重复。当逻辑发生变化时，这会变得更加痛苦，并且会在系统中产生级联。例如，假设您的/updateBlog 授权现在有“访客更新者”。必须对您的/updateBlog 服务和网关进行同步更新比较棘手，而且成本更高。

故事的寓意是，在边境进行身份验证，在服务中进行授权。