在学习oauth2.0协议的时候，对于刷新令牌refresh token感觉很困惑。主要是为啥需要刷新令牌，以及刷新令牌是如何工作的，技术细节是啥？比如通过refresh token可以让access token永久不过期吗？
下面就针对这两个问题进行详细分析。
为什么需要刷新令牌
刷新令牌的生命周期
1. 授权服务颁发刷新令牌
2. 第三方服务使用刷新令牌
定时检测方式和现场发现方式
3. 授权服务校验刷新令牌
1. 接收刷新令牌请求，验证基本信息
2. 重新生成访问令牌
为什么需要刷新令牌
如果access token超时时间很长，比如14天，由于第三方软件获取受保护资源都要带着access token，这样access token的攻击面就比较大。
如果access token超时时间很短，比如1个小时，那其超时之后就需要用户再次授权，这样的频繁授权导致用户体验不好。
引入refresh token，就解决了【access token设置时间比较常，容易泄露造成安全问题，设置时间比较短，又需要频繁让用户授权】的矛盾。
刷新令牌的生命周期
1. 授权服务颁发刷新令牌
第三方软件得到一个访问令牌的同时，也会得到一个刷新令牌，refresh_token是与第三方软件、用户关联在一起的
2. 第三方服务使用刷新令牌
什么时候来使用刷新令牌呢？
定时检测方式
在第三方软件收到访问令牌的同时，也会收到访问令牌的过期时间expires_in。一个设计良好的第三方应用，应该将expires_in值保存下来并定时检测；如果发现expires_in即将过期，则需要利用refresh_token去重新请求授权服务，以便获取新的、有效的访问令牌。
现场发现方式
比如第三方软件访问受保护资源的时候，突然收到一个访问令牌失效的响应，此时第三方软件立即使用refresh_token来请求一个访问令牌，以便继续代表用户使用他的数据。
综合来看的话，定时检测的方式，需要额外开发一个定时任务；而“现场”发现，就没有这种额外的工作量。具体采用哪一种方式，你可以结合自己的实际情况。不过呢，建议采用定时检测这种方式，因为它可以带来“提前量”，以便有更好的主动性，而现场发现就有点被动了。
3. 授权服务校验刷新令牌
第三方软件发送请求
授权服务器会先比较grant_type和 refresh_token的值，确认是请求刷新令牌的操作
1. 接收刷新令牌请求，验证基本信息
1）和颁发访问令牌前的验证流程一样，这里我们也需要验证第三方软件是否存在。
在使用刷新令牌的时候，也是需要应用传递它的app_id和app_sercet的
2）验证刷新令牌是否存在，要保证传过来的刷新令牌的合法性。
3）还需要验证刷新令牌是否属于该第三方软件。授权服务是将颁发的刷新令牌与第三方软件、当时的授权用户绑定在一起的，因此这里需要判断该刷新令牌的归属合法性。
2. 重新生成访问令牌
访问令牌access_token，其与第三方软件、用户，还有授权范围scope绑定在一起。
在生成access_token的时候，要考虑下面的场景。
1）若access_token未超时，那么进行refresh_token有下面几种方式：
不会改变access_token，但超时时间会刷新，相当于续期access_token
更新access_token的值，我们建议【统一更新access_token的值】
在spring security oauth中，其处理方式是仍返回原access_token及refresh_token，但是并不会续期，expires_in保持原样，所以我们看到下面的响应
2）若access_token超时了，但是refresh_token未超时，那么更新access_token的值，但是刷新令牌refresh_token呢？推荐刷新令牌是一次性的，使用之后就会失效。
注意：通过refresh_token刷新后，返回来assessToken和refresh_token，但refresh_token过期时间不会重新刷新。
3）若refresh_token也超时了，就需要将刷新令牌和访问令牌都放弃，相当于回到了系统的初始状态，只能让用户小重新授权了。
谢谢关注张军博客
本文为张军原创文章,转载无需和我联系,但请注明来自张军的军军小站,个人博客http://www.zhangjunbk.com
