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

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

• 客户服务
• 认证服务
• 订阅服务
• 博客服务
• 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（）=>博客服务:: createBlog（）

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

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

2. cms-api-gw / frontend-api-gw :: listBlogs（）=>博客服务:: listBlogs（）

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

我的想法：

In case A, the logic in each individual microservice is more complicated because of authorization layer. Can get more complicated where there will be more API gws, user roles etc. However API GW in this case is simpler and it only forwards requests to microservices.

In case B, the logic in each individual microservice is less complicated, simple and straightforward. However there is more logic in API GW because it has to implement authorization for all platform (at least for the part that this api gw is responsible for). Maybe it can be also advantage to have all authorization in one place and not spread across microservices?

Also in case B there is less coupling between individual microservices I think.

What do you guys think of those two approaches / maybe you have other "ideas"?