为什么refresh_token不是由响应"client_credentials“授权的OAuth2服务器提供的？
我正在阅读OAuth2规范：
https://www.rfc-editor.org/rfc/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"
}`
我有点困惑，为什么授权服务器可以返回refresh_tokens，用于password授予类型，而不能返回client_credentials。
我猜想这与refresh_token可以交换为access_token这一事实有关，而且由于client_credentials授予类型不需要用户名和密码，如果应用程序密钥和refresh_token被破坏，那么撤销变得更加困难。
回答 3
Stack Overflow用户
发布于 2015-03-24 22:51:09
当使用客户端凭据授予时，客户端应用程序使用其客户端id和客户端机密向授权服务器进行身份验证。如果授权的话，它将获取资源的访问令牌。在这个场景中没有用户交互，因此不需要发出刷新令牌。
当访问令牌过期时，客户端可以使用自己的凭据请求新令牌。当客户端希望代表用户访问资源时(此时可能不与客户端交互)，就会使用刷新令牌。
在这种情况下，客户端代表自己行事。
Stack Overflow用户
发布于 2015-03-25 21:12:18
当应用Resource密码凭据授予时，返回刷新令牌是有意义的，这样客户端不需要存储或缓存资源所有者的密码(最初由资源所有者以交互方式提供)才能获得新的访问令牌。
在客户端凭据流中，客户端的凭据无论如何都是从存储中提供的--以脱机的方式--因此刷新令牌与重新使用客户端凭据相比没有任何安全性或可用性优势(客户机无论如何都可以访问这些凭证)来获得新的访问令牌。
Stack Overflow用户
发布于 2017-03-31 21:55:52
理解这一点的关键部分是，refresh概念的设计并不是为了刷新您已经拥有的访问令牌。
“刷新令牌”只是一种跳过终端用户干预的方法，如果您的应用程序正在使用最终用户用户名/密码身份验证(即代表特定的最终用户行事)，则仍然可以重新获得一个新的访问令牌。(如果我是设计人员，我可能会将“刷新令牌”命名为“旁路用户干预令牌”，因此不需要问当前的问题。)
但是，如果您的应用程序使用客户端凭据进行身份验证，则它是代表自己进行身份验证的，您根本不需要用户干预，服务器也不需要(也不会)为您提供刷新令牌。
https://stackoverflow.com/questions/29233772
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号