Question

我正在阅读OAuth2规范：

https://tools.ietf.org/html/rfc6749#section-4.4.2

特别是client_credentials授予类型的部分。

如果访问令牌请求有效且授权，则为   授权服务器按章节中的描述发出访问令牌   5.1。
  不应包含刷新令牌。如果请求未通过客户端身份验证或无效，则授权服务器   返回错误响应，如第5.2节所述。

成功回应的示例：

 HTTP/1.1 200 OK
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache

 {
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "example_parameter":"example_value"
 }

`

我有点困惑为什么授权服务器可以为password授权类型返回refresh_tokens，但不能为client_credentials返回。

我猜测它与refresh_token可以交换access_token这一事实有关，因为如果你的应用程序键和refresh_token，client_credentials grant类型不需要用户名和密码是否妥协撤销变得更加困难？

Answer 1

使用客户端凭据授予时，客户端应用程序使用其客户端ID和客户端密钥向授权服务器进行身份验证。如果获得授权，它将获取资源的访问令牌。在这种情况下没有用户交互，因此不需要发出刷新令牌。

当访问令牌过期时，客户端可以使用自己的凭据来请求新令牌。当客户端想要代表用户访问资源时（当时可能不与客户端交互），将使用刷新令牌。

在这种情况下，客户代表自己行事。

Answer 2

在应用资源所有者密码凭据授予时，返回刷新令牌是有意义的，这样客户端就不需要存储或缓存资源所有者的密码 - 最初由资源所有者以交互方式提供 - 以获取一个新的访问令牌。

在客户端凭据流中，客户端的凭据无论如何都是以存储的方式提供的 - 因此刷新令牌不会再获得任何安全性或可用性优势，而只是再次重新使用客户端凭据（客户端具有无论如何访问那些）获取新的访问令牌。

Answer 3

理解这一点的关键部分是，refresh概念并非旨在让您刷新已有的任何访问令牌。

“刷新令牌”只是一种跳过最终用户干预并仍然重新获得新访问令牌的方法，如果您的应用使用最终用户用户名/密码身份验证，即代表特定的最终用户行事。（如果我是设计师，我可能会将“刷新令牌”命名为“绕过用户干预令牌”，因此不需要询问当前的问题。）

但是，如果您的应用使用客户端凭据进行身份验证，则代表自己采取行动，您根本不需要用户干预，服务器不需要（也不会）给您一个刷新令牌。

为什么OAuth2服务器不提供refresh_token响应“client_credentials”授权？

3 个答案: