在我对 OAuth2 的理解中，范围可用于指定对代码所有者要求和授予的内容的访问权限。
在大多数情况下，我遇到范围列表已关闭并指定可以访问的“种类”，例如profile、email、openid from Google Sign-in。
对范围内特定资源的访问进行编码是否有意义？点赞帐号：{帐号}：rw
这是针对用户拥有由资源服务器管理的多个不同资源并希望授权第三方访问特定资源而不是“种类”资源的情况。例如，假设的应用程序将管理数据文件夹，用户 U 将授予对其文件夹“/A”的读取访问权限，但不授予应用程序 B 的任何其他文件夹的读取权限
我知道在这种情况下，授权和资源服务器都必须解析并专门处理这种开放式范围。
这种方法还有其他问题吗？
对于这种情况，OAuth2 甚至是正确的技术吗？如果不是用什么代替？
我认为 OAuth 范围的目的是为委托同意提供一个框架，这是一种自由授权的形式，但与策略驱动的授权不同，这听起来像是你想要完成的。资源服务器有责任执行委托和策略驱动的方法。范围最终就像一个声明，如果您尝试对策略驱动的授权进行建模并类似于基于角色的访问控制，它将随着权限（操作-资源）矩阵（读取帐户、写入帐户等）呈指数增长。 ) 您的资源服务器开发人员必须知道每个作用域要强制执行的含义：@PreAuthorize("#oauth2.hasScope('read-account')") 这样您就可以看到可能产生的复杂 if-then-else 逻辑。
考虑通过让资源服务器使用它拥有的所有上下文（id_token 属性、资源元数据、客户端足迹、范围）来将您的策略决策从您的资源服务器外部化，以使用“can [subject] do [action] 发出策略决策服务请求在这个 [context/env] 中的 [resource] 上？” 策略决策服务是一个域，其中包含您的风险、上下文和策略驱动的规则，例如“当资源所有者与帐户所有者有关系时，使用 2 因素身份验证时，外部客户端可以读取帐户详细信息”。寻找支持标准的服务，例如 XACML 的 JSON 配置文件。这将防止您陷入范围爆炸，并有助于实现更具凝聚力的政策。
TL; 博士；
这是一个设计缺陷。范围代表资源，并与您的客户端（应用程序）相关联，通知此应用程序可以访问该资源。这种粒度级别不是一个好主意。在这种情况下，您将得到一个非常难以维护的列表，我想说的是应用程序（而不是用户）的权限。这不是应该做的。
其定义中的范围是识别资源的值，而不是特权。当您将范围发送到授权服务器时，您通过范围通知您希望通过您的客户端（即应用程序）访问哪些资源 - 而不是您的用户。这是您的资源，它应该解释呈现访问令牌（带有范围）的用户是否合法访问它。
您询问了 OAuth2 中的范围，但请记住 OAuth2 只是 AUTHORIZATION 的框架，而不是为身份验证定义的。对于用户身份验证，您应该使用例如基于 OAuth2 构建的 OpenIDConnect (OIDC)。
OIDC 呈现身份令牌，它是用户数据的载体。如果您从授权服务器获取身份令牌和访问令牌，则您的资源将决定特定用户是否有权访问他想要的数据。