我正在设计一个基于微服务的应用程序，其中包含两个 API 端点，其中一个用于用户访问。使用 JWT 进行身份验证的用户可以属于不同的组织，这些组织又按层次结构进行组织。每个用户都可以具有一些角色，这些角色是为每个组织类型定义的;组织和角色的组合定义了可以从用户(方法和资源(访问哪个 API。总之，它可能会变得一团糟！
有几个提供 ACL 功能的库，但我想知道将它们放在哪里：第一个解决方案似乎是 API 网关，它应该为每个请求调用一个组件。
-JWT 包括用户的角色 ID 列表 -API 网关验证 JWT 并使用角色 ID 在表中查找，其中每个角色都有一个权限列表(例如，可以 POST/users( -如果角色与请求匹配，则后者将转发到正确的服务;否则，网关响应 403
其他选择是将"身份验证服务"放入体系结构中。网关只是将所有请求转发到正确的服务，每个服务(可能依赖于公共库(将令牌发送到身份验证服务并请求授予以满足请求。在这种情况下，身份验证服务是/auth 资源下所有请求的"正确服务"，提供登录/注销、令牌刷新和新用户的注册(例如当您单击登录邮件中提供的链接时(
第一种解决方案提供了一个"胖网关"，它在逻辑上有一个很小的层，但强制所有服务只响应安全调用，分解掉所有身份验证/orization逻辑，并且不添加依赖
关系，但- 这是正确的方法吗？
- 是否有提供该功能的 API 网关实现
- 这两种方法还有其他一些我没有看到的优点/缺点
谢谢你的回答!!
我回来分享我对围绕帖子主题所做的选择的看法。我遵循的方式是
API 网关知道随请求一起发送的身份验证数据( 实践中的"授权标头"(并进行验证。智威汤逊携带 所有必要的信息，以便 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 数据执行 GET 身份，以验证身份是否存在以及一切正常。此外，令牌生成/刷新不是 api 网关的问题，但有一个身份验证服务器(一个是独立的，另一个仍然嵌入到整体中(。所有这些都会产生大量负载，但这可以通过"标识"缓存轻松缓解。只注意在标识发生突变时使缓存失效，或者尽量使用更少的信息，这样您就可以只关心身份删除
我们的下一步将是制作/购买一个更结构化的身份验证服务器，它将与网关集成，但能够独立扩展，更清晰，更易于配置，可能带有某种UI。
作为云原生粉丝，我也在研究具有身份验证功能的 istio，但我仍然需要了解是否适合我的方法，该方法需要能够进行一些自定义