从0构建Oauth2Server服务之Refreshing-access-tokens

刷新令牌 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服务构建的资料请关注编程网其它相关文章！