在学习oauth2.0协议的时候，对于刷新令牌refresh token感觉很困惑。主要是为啥需要刷新令牌，以及刷新令牌是如何工作的，技术细节是啥？比如通过refresh token可以让access token永久不过期吗？

下面就针对这两个问题进行分析。

如果access token超时时间很长，比如14天，由于第三方软件获取受保护资源都要带着access token，这样access token的攻击面就比较大。 如果access token超时时间很短，比如1个小时，那其超时之后就需要用户再次授权，这样的频繁授权导致用户体验不好。

引入refresh token，就解决了【access token设置时间比较常，容易泄露造成安全问题，设置时间比较短，又需要频繁让用户授权】的矛盾。

第三方软件得到一个访问令牌的同时，也会得到一个刷新令牌，refresh_token是与第三方软件、用户关联在一起的

什么时候来使用刷新令牌呢？

在第三方软件收到访问令牌的同时，也会收到访问令牌的过期时间expires_in。一个设计良好的第三方应用，应该将expires_in值保存下来并定时检测；如果发现expires_in即将过期，则需要利用refresh_token去重新请求授权服务，以便获取新的、有效的访问令牌。

比如第三方软件访问受保护资源的时候，突然收到一个访问令牌失效的响应，此时第三方软件立即使用refresh_token来请求一个访问令牌，以便继续代表用户使用他的数据。 综合来看的话，定时检测的方式，需要额外开发一个定时任务；而“现场”发现，就没有这种额外的工作量。具体采用哪一种方式，你可以结合自己的实际情况。不过呢，建议采用定时检测这种方式，因为它可以带来“提前量”，以便有更好的主动性，而现场发现就有点被动了。

第三方软件发送请求 授权服务器会先比较grant_type和 refresh_token的值，确认是请求刷新令牌的操作

1）和颁发访问令牌前的验证流程一样，这里我们也需要验证第三方软件是否存在。

在使用刷新令牌的时候，也是需要应用传递它的app_id和app_sercet的

2）验证刷新令牌是否存在，要保证传过来的刷新令牌的合法性。

3）还需要验证刷新令牌是否属于该第三方软件。授权服务是将颁发的刷新令牌与第三方软件、当时的授权用户绑定在一起的，因此这里需要判断该刷新令牌的归属合法性。

访问令牌access_token，其与第三方软件、用户，还有授权范围scope绑定在一起。

在生成access_token的时候，要考虑下面的场景。

1）若access_token未超时，那么进行refresh_token有下面几种方式：

2）若access_token超时了，但是refresh_token未超时，那么更新access_token的值，但是刷新令牌refresh_token呢？推荐刷新令牌是一次性的，使用之后就会失效。

注意：通过refresh_token刷新后，返回来assessToken和refresh_token，但refresh_token过期时间不会重新刷新。

3）若refresh_token也超时了，就需要将刷新令牌和访问令牌都放弃，相当于回到了系统的初始状态，只能让用户小重新授权了。