0

流程是这样的：

  1. 我们有一个注册了特定资源 ID 的 oauth 应用程序，所以这个应用程序可以访问那些
  2. 一段时间后，需要添加另一个资源 ID，因为我们正在扩展客户端应用程序的功能
  3. 客户端应用程序有时会刷新令牌，这可能是由于错误或 access_token 过期。
  4. 在新的 access_token 上使用 check_token 为我们提供了一组旧的资源 ID。似乎它取自某些缓存或旧令牌本身。

问题：不应该刷新令牌也刷新资源 ID？这是反对oauth rfc（在其中找不到有关此特殊情况的任何信息）吗？

我们当然可以撤销 oauth 应用程序的所有令牌，但这需要我们所有的用户再次登录，这是我们想要避免的。

我不确定它是否与弹簧云安全性或更确切地说是 oAuth 本身有关。C

4

1 回答 1

1

此答案假定您的资源标识符等同于 OAuth2 描述的范围，因为从您的描述来看，它们的目的似乎非常相似 - 限制访问令牌的范围。

在发出访问令牌刷新请求时，规范声明您可以包含一个scope参数，但是：

访问请求的范围如第 3.3 节所述。请求的范围不得包括资源所有者最初授予的任何范围，如果省略，则视为等于资源所有者最初授予的范围。

此外，作为响应的一部分，可以发出一个新的刷新令牌，但同样：

授权服务器可以发布一个新的刷新令牌 (...)如果一个新的刷新令牌被发布，刷新令牌的范围必须与客户端在请求中包含的刷新令牌的范围相同。

（重点是我的，规范的第 6 节）

这意味着，根据规范，将新范围/资源自动添加到访问令牌是不合规的。但是，您不需要注销用户，您只需要请求资源所有者对新范围的同意。

同样，这是规范中关于似乎与您的使用场景相匹配的范围的说明。但是，在某些情况下，这不会如此严格地适用，或者最终不会产生真正的影响。如果单个组织控制授权服务器和客户端应用程序，它可以决定某些应用程序享有有时称为管理同意的内容，这基本上是不要求资源所有者明确同意，因为这是一个受信任的应用程序。在这些情况下，您可以在没有任何类型的用户干预的情况下增加范围/资源。

于 2016-10-26T10:15:50.203 回答