有一个具有整体架构的遗留应用程序，主要目标是用微服务架构风格重构此应用程序。遗留应用具有复杂的安全模型，实际上用户可以有多个角色，每个角色可以有多个权限，每个权限可以有多个属性。有一个想法是使用api-gateway作为oauth2.0客户端的模式，并保护所有资源。在当前的设置中，api-gateway使用包含openid的作用域运行authorization code flow，因此它收到三个主要部分：accessToken、idToken和用户authorities，并将它们存储在会话cookie下。此外，在当前设置中，Token Relay过滤器用于将accessToken发送到资源。
有几个问题：
1.在资源服务器级别（受保护的微服务）上验证细粒度权限是否被视为最佳实践？如果是，如何提供用户authorities，因为Token Relay只提供accessToken？
1.有什么理由在api-gateway端使用openid scope运行authorization code flow吗？如果是，在哪些情况下可以带来价值？
1条答案
按热度按时间f0ofjuux1#
A1
细粒度授权应该在资源服务器中完成。这种逻辑会经常发展，最好由API团队管理。您的旧版应用程序（网站？）似乎在充当资源服务器，并在这方面做得很好。另请参阅我最近的回答，了解如何跨多个API工作。
所使用的授权值应该从访问令牌中的声明派生。例如在那里发布用户标识和角色。然后查找次要值。请参阅这个示例oauth filter和这个服务逻辑类来了解实现这一点的一种方法。
A2
避免在API请求的服务器端触发OIDC流。这是一件坏事，因为它阻止了移动的应用程序或单页应用程序或iframe调用您的API。然后服务器重定向一个不应该重定向的调用者，例如Ajax请求。一个更好的选择是在客户端没有有效令牌时向其返回401。
相反，每个客户端应该通过与授权服务器（AS）交互来管理自己的身份验证流。对于Web客户端，前端的后端通常是客户端。这与API不同。客户端始终触发其自己的OIDC流，从而实现最干净的分离。为应用程序和团队提供最佳效果。
网关角色
API网关是处理API请求期间客户端特定安全差异的理想场所。一个好的网关可以运行可以执行自定义安全逻辑的插件。您应该只是偶尔需要重新部署或重新配置网关，而API会经常更改。
一个插件用例是用于使用安全cookie的SPA。网关可以打开cookie，应用特定于Web的安全检查，例如CORS和CSRF，然后将JWT访问令牌转发到API。这将Web关注点排除在API之外，这样API就可以被所有类型的客户端同样调用。