我有一个使用Identity Server 4并打开id connect进行身份验证和授权的应用程序。我现在正在与系统架构师进行讨论，该系统架构师在处理用户权限时希望进行一些更改。在此应用程序中，用户可以是单个或多个区域的一部分，并且在该区域内，用户可以是单个或多个客户的一部分。这些用户既具有区域角色，又具有客户角色。在每个区域内，用户（在最坏的情况下，但很可能发生的情况）可以成为超过150个客户的一部分，每个客户在每个角色中具有不同的角色，这总共可能导致2500个权限。
当用户浏览应用程序时，此人选择用户当前正在浏览的不同区域和客户。这意味着，根据资源当前正在使用的区域/客户，用户在资源内具有不同的权限。我的系统架构师建议将这些权限存储在发送给资源的访问令牌中，以便资源检查是否允许用户对指定的区域/客户执行此操作，并且这些权限声明应在何时更新用户更改区域和/或客户。我担心的是，这些权限似乎太动态了，无法在访问令牌中处理，因为在应用程序内的用户会话期间，这些权限可能会多次更改，
首先，甚至可以告诉身份服务器“用户A刚刚选择了该区域/客户，请更新令牌中的所有声明以匹配该区域/客户”，如果是这样，我将如何处理？将当前选定地区和客户的信息传递到个人资料服务/用户信息端点（无需将每个地区/客户建模为自定义声明）？
第二，我担心这太动态了，无法存储在令牌中，因为它将在用户会话中多次更改。由于用户登录的是应用程序本身，而不是每个区域和客户，因此我的建议是将此逻辑放在api /资源中，以便当某个请求到达API时，我们将检查权限数据库或缓存也可以查看用户针对区域执行的操作以及客户针对该操作执行的操作。我的理解是，OpenID Connect和OAuth不应真正按照他的建议使用，但我可能错了吗？
我已经读过this arcticle by leastprivilege，它似乎可以解决我所说的相同问题，但是我的系统架构师似乎并不那么相信。
答案 0 :(得分：3)
PolicyServer是上述文章的后续内容。
我可以重复这里写的内容，但总之：授权很困难，权限不应该是访问令牌的一部分。
与身份验证不同，授权是特定于上下文的，并且在不同级别上运行。这使得访问令牌不是获得权限的最佳位置。您还遇到了更新版权声明等问题。
IdentityServer的主要目的是处理用户的身份验证和全局授权（例如，哪个客户端可以访问哪个资源）。
为了获得授权，他们创建了PolicyServer，其中授权已成为向Identity添加权限（声明）的独立机制。在OSS版本中，这是通过本地中间件完成的，但在付费版本中，这是单独的服务器。
授权上下文基于客户端，资源和用户。当您将其用作“键”时，可以为此上下文添加声明。使其在微服务架构中非常有用。
还请记住，某些授权可以基于资源。例如。 WebsiteAdmin表中用户的存在可以暗示该用户是网站管理员。或者仅在用户创建文档时才向用户提供该文档。