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

Question

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

• 帐户服务
• 授权服务
• 订阅服务
• 博客服务
• api网关

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

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

• 前端（针对客户）
• cms（对于管理员）

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

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

1. frontend-api-gw::createBlog() => blog-service::createBlog()

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

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

2. cms-api-gw / frontend-api-gw::listBlogs() => blog-service::listBlogs()

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

我的想法：

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

在情况 B 中，每个单独的微服务中的逻辑不那么复杂、简单和直接。但是API GW中有更多的逻辑，因为它必须为所有平台实现授权（至少对于这个api GW负责的部分）。也许将所有授权集中在一个地方而不是跨微服务传播也是一种优势？

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

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

Answer 1

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

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

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

这个故事的寓意是，在边境认证，在服务中授权。