目录
刷新令牌 Refreshing-access-tokens
如何让您的开发人员使用刷新令牌来获取新的访问令牌。如果您的服务随访问令牌一起发出刷新令牌，则您需要实现此处描述的刷新授权类型。
请求参数
访问令牌请求将包含以下参数。
grant_type（必需的）
该grant_type参数必须设置为“refresh_token”。
refresh_token（必需的）
先前颁发给客户端的刷新令牌。
scope（选修的）
请求的范围不得包括未在原始访问令牌中发布的其他范围。通常这不会包含在请求中，如果省略，服务应该发出一个与之前发出的范围相同的访问令牌。
客户端身份验证（如果客户端被授予机密则需要）
通常，刷新令牌仅用于机密客户端。但是，由于可以在没有客户端密码的情况下使用授权代码流，因此没有密码的客户端也可以使用刷新授权。如果向客户端发出了一个秘密，则客户端必须对该请求进行身份验证。通常，该服务将允许附加请求参数client_id和client_secret，或者接受 HTTP 基本身份验证标头中的客户端 ID 和密码。如果客户端没有密码，则此请求中不会出现客户端身份验证。
验证刷新令牌授予
在检查了所有必需的参数并验证了客户端（如果向客户端发出了秘密）之后，授权服务器可以继续验证请求的其他部分。
然后服务器检查刷新令牌是否有效，并且没有过期。如果刷新令牌已颁发给机密客户端，则服务必须确保请求中的刷新令牌已颁发给经过身份验证的客户端。
如果一切正常，该服务可以生成访问令牌并做出响应。服务器可能会在响应中发出新的刷新令牌，但如果响应不包含新的刷新令牌，则客户端会假定现有的刷新令牌仍然有效。
例子
以下是服务将接收的刷新授权示例。
POST /oauth/token HTTP/1.1 Host: authorization-server.com grant_type=refresh_token &refresh_token=xxxxxxxxxxx &client_id=xxxxxxxxxx &client_secret=xxxxxxxxxx
Response
对刷新令牌授予的响应与发出访问令牌时的响应相同。您可以选择在响应中发出新的刷新令牌，或者如果您不包含新的刷新令牌，则客户端假定当前的刷新令牌将继续有效。
以上就是从0构建Oauth2Server服务之Refreshing-access-tokens的详细内容，更多关于Oauth2Server服务构建的资料请关注其它相关文章！
