从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服务构建的资料请关注编程网其它相关文章!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341