我正在设计一个带有两个API端点的基于微服务的应用程序，其中一个用于用户访问。通过JWT进行身份验证的用户可以属于不同的组织，这些组织又按层次组织。每个用户都可以拥有一些角色，这些角色是为每种组织类型定义的;组织和角色之间的组合定义了可以从用户访问哪个API（方法和资源）。总之，它可能变得一团糟！
有几个库提供ACL功能，但我想知道在哪里放置它们：第一个解决方案似乎是API网关，它应该为每个请求调用一个组件。
- JWT包含用户-API网关的角色ID列表，用于验证JWT，并使用角色Ids在表中查找，其中每个角色都有一个权限列表（例如，可以POST / users） - 如果角色与请求匹配，后者被转发到正确的服务;否则，网关以403响应
其他选择是将“auth-service”置于架构中。网关只是转发所有传递给正确服务的请求，每个服务（可能依赖于公共库）将令牌发送给auth服务并请求授权以满足请求。在这种情况下，auth服务是/ auth资源下所有请求的“正确服务”，提供登录/注销，令牌刷新和新用户注册（例如，当您单击提供到登录邮件中的链接时）
第一个解决方案提供了一个“胖网关”，它在逻辑上有一个很小的层，但强制所有服务只响应安全调用，将所有身份验证/编码逻辑分解出来，而不是在服务之间添加依赖关系。
谢谢你的答案!!!
我回来分享我对围绕帖子主题做出的选择的看法。我遵循的方式是
API网关知道与请求一起发送的身份验证数据（实际上是“授权标头”）并进行验证。 JWT携带所有必要的信息，因此api网关可以应用其下游服务未知的策略。
在我的架构中有一些RBAC，没有什么可以放在jwt中，所以我们在网关上移动了访问控制逻辑。我们调整了一个自定义nodejs库作为插件，但我不得不承认已经弄乱了我们的网关，我们发现authz配置很慢且容易出错。在这方面，我们正在支付缺乏与主要配置信息的集成。这会是有用的
routes:
- route1:
path: /foos/:fooid/bar
downstreamService: http://foo.cluster
authz:
readerRole:
- GET
writerRole:
- POST
all:
- OPTIONS
但是，Api网关不能单独完成所有工作：需要联系我称之为“身份提供商”的服务，那些将“消费者”概念模型化的平台包含在用户，设备，应用程序中。我们的api网关基于JWT数据执行身份认证，以验证身份是否存在且一切正常。此外，令牌生成/刷新不是api网关关注的问题，但是有一个auth服务器（一个是独立的，另一个仍然嵌入到整体中）是conctaced。所有这些都会产生很多负载，但这可以通过“identites”缓存轻松减轻。只是知道在身份变异时使缓存无效，或者在leat尝试使用尽可能少的信息，这样你就可以关心身份删除了
我们接下来的步骤将是制作/购买更结构化的auth服务器，该服务器将与网关集成，但能够独立扩展，更清晰，易于配置，可能具有某种UI
作为云原生粉丝，我也在看istio，其中包括auth功能，但我仍然需要了解是否适合我的方法需要能够进行一些定制