我应该在api网关级别还是在资源服务器（受保护的微服务）上进行授权（权限检查）？

Question

存在具有单体架构的遗留应用程序，主要目标是使用微服务架构风格重构该应用程序。遗留应用程序具有复杂的安全模型，实际上用户可以有多个角色，每个角色可以有多个权限，每个权限可以有多个属性。有想法使用 api-gateway 充当 oauth2.0 客户端的模式并保护后面的所有资源。在当前设置中，api-gateway 运行

authorization code flow

，范围包括

openid

，因此它收到三个主要部分：

accessToken

、

idToken

和用户

authorities

，并将它们存储在会话 cookie 下。此外，在当前设置中，

Token Relay

过滤器用于将

accessToken

发送到资源。

有几个问题：

1. 在资源服务器级别（受保护的微服务）验证细粒度权限是否被认为是最佳实践？如果是，如何提供用户

   authorities

   ，因为

   Token Relay

   只提供

   accessToken

   ？
2. 是否有任何理由在 api 网关端以

   authorization code flow

   范围运行

   openid

   ？如果是的话，什么情况下可以带来价值？

Answer 1

A1。细粒度的授权应该在资源服务器中完成。您的遗留应用程序（网站？）似乎充当资源服务器并且做得很好。另请参阅 我最近的回答，了解它如何跨多个 API 工作。

使用的授权值应源自访问令牌中的声明。例如，在那里发布用户身份和角色。然后查找辅助值。请参阅此示例 oauth 过滤器和此服务逻辑类了解实现此目的的一种方法。

A2。避免在 API 请求的服务器端触发 OIDC 流。这是一件坏事，因为它会阻止移动应用程序或单页应用程序或 iframe 调用您的 API。然后，服务器重定向不应重定向的调用者，例如 Ajax 请求。更好的选择是当客户端没有有效令牌时，仅向客户端返回 401。

相反，每个客户端应该通过与授权服务器（AS）交互来管理自己的身份验证流程。对于 Web 客户端，前端的后端通常是客户端。这与 API 不同。客户端始终触发自己的 OIDC 流，从而实现最干净的分离。获得最好的结果。