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

Question

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

我正在考虑实现api-gw模式，其中除api-gw之外的所有微服务都将部署到专用网络（在该微服务中，它们将能够通过消息代理直接或同步或异步地彼此通信），并且它们将公开可用仅通过api-gw。

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

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

我的问题是关于授权及其授权地点（或者不同方法的优缺点）。让我们关注两个“端点”：

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

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

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

我的想法：

在情况A中，由于授权层，每个单独的微服务中的逻辑更加复杂。在会有更多API gws，用户角色等的情况下，可能会变得更加复杂。但是，在这种情况下，API GW更简单，它仅将请求转发到微服务。

在情况B中，每个单独的微服务中的逻辑都不太复杂，简单明了。但是，API GW中有更多逻辑，因为它必须对所有平台（至少是此api gw负责的部分）实施授权。将所有授权都集中在一个地方而不分散到微服务中也许也很有利？

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

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

Answer 1

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

例如，假设您要授权/ updateBlog？id = 52143方法。在网关中执行此操作不仅要知道该用户已获得授权，而且还拥有该特定博客，或者他们有权更新委派给他们的博客。

将所有这些逻辑导出到网关是可能的，但是很棘手，最终会造成高度重复。当逻辑改变时，这变得更加痛苦，并且在整个系统中具有级联。例如，假设您的/ updateBlog授权现在具有“来宾更新程序”。必须同时同步/ updateBlog服务和网关的更新比较棘手，并且更昂贵。

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