我很难问这个问题，所以让我向您解释一下我们半生不熟的 OAuth 2.0 解决方案：
目前，我们只使用受信任的授权，而不是我们要求用户名和密码。如果这些凭据成功通过身份验证，我们将发出访问令牌和刷新令牌。但是，该响应消息中没有范围信息。OAuth2 规范说，如果在请求中提供了范围，那么它也需要在响应中返回，但前提是授予的范围与请求的范围不同。在任何情况下，我们都没有为令牌分配范围，只有一个表示用户已通过验证的令牌。这对我来说感觉不对，但也许我想多了。
稍后在我们的流程中，客户端将尝试访问受保护的资源，例如登录到仅授予特定角色的网站。因此，虽然您可能已通过身份验证（您拥有访问令牌），但由于您的角色，您可能无法登录此站点。我们当前验证这一点的方式是将访问令牌发送到资源端点。然后，该端点将令牌与您尝试访问的 uri 一起发送到我们的验证服务器，该服务器验证您的令牌是好的，并且您的角色（我们通过数据库中的令牌条目查找）允许您访问资源，然后返回 200 以允许您继续或 403 表示您无权访问该端点。所以换句话说，访问令牌没有直接分配给它的任何范围，相反，它只是告诉我们您是谁，然后我们查找您的权限并将其与请求进行比较，然后说是或否。这对我来说似乎很奇怪。
在我见过的其他实现中，我得到的印象是它实际上应该像这样工作：
- 您请求访问令牌，如果您的凭据成功验证，则会生成一个令牌。
- 然后，身份验证服务器查看您请求的范围，然后在数据库中生成一个令牌以及您请求的范围的批准部分（部分或完整）。相反，如果您请求 abc 和 d，但只有 b 和 d 获得批准，则存储在我们数据库中的令牌将反映该令牌仅允许 b 和 c。
- 令牌字符串与批准的范围一起被发送回客户端。
- 在受保护的资源请求期间，我们在数据库中查找令牌并将请求的资源与所提供令牌的范围条目中的内容进行比较，然后返回是或否，而不是查找用户权限。
那么有什么区别呢？我的印象是 TOKEN 包含范围。因此，如果用户 A 被允许资源 ABCD 和 E，但请求 BC 和 F，那么令牌将只对 B 和 C 有利。我们不简单地授予 A，因为他被允许这样做；他没有要求 AD 或 E 并且他没有被允许 F 所以令牌不允许他们。那有意义吗？
所以我的问题是这个。根据我对它应该使用的方式的理解，我们当前的实现是否错误？我的理解正确吗？