access token 是应用方访问资源服务器的接口时，需要提供的一个令牌。拥有这个令牌代表着得到用户的授权。然而，这个授权应该是临时的，有一定有效期。这是因为，access token 在使用的过程中可能会泄露。给 access token 限定一个较短的有效期可以降低因 access token 泄露而带来的风险。
然而引入了有效期之后，应用方使用起来就不那么方便了。每当 access token 过期，应用方就必须重新向用户索要授权。这样用户可能每隔几天，甚至每天都需要进行授权操作。这是一件非常影响用户体验的事情。希望有一种方法，可以避免这种情况。
于是 Oauth2.0 引入了 refresh token 机制。refresh token 的作用是用来刷新 access token。鉴权服务器提供一个刷新接口，例如：
http://xxx.xxx.com/refresh?refreshtoken=&client_id=
传入 refresh token 和 client_id，鉴权服务器验证通过后，返回一个新的 access token。为了安全，Oauth2.0 引入了两个措施：
1，Oauth2.0 要求，refresh token 一定是保存在应用方的服务器上的，而绝不能存放在狭义的客户端（例如移动 app、PC端软件） 上。调用 refresh 接口的时候，一定是从服务器到服务器的访问；
2，Oauth2.0 引入了 client_secret 机制。即每一个 client_id 都对应一个 client_secret。这个 client_secret 会在应用方申请 client_id 时，随 client_id 一起分配给客户端。应用方必须把 client_secret 妥善保管在服务器上，决不能泄露。刷新 access token 时，需要验证这个 client_secret。
于是，实际上的刷新接口应该是类似这样的：
https://xxx.xxx.com/refresh?refreshtoken=&client_id=&client_secret=
不过，实际当中通常不会把client_secret放在url中，具体怎么传递及验证由各个平台自己决定。
应用方什么时候需要用refresh token来刷新access token呢？当应用方调用资源接口，并接收到返回“access token已过期”的错误时，应用方应当尝试用refresh token去刷新access token，而不是让用户重新授权。
虽然refresh token也会过期，但是通常有效期非常长。在设计refresh token相关的api时，需要非常慎重地考虑refresh token和client_secret的安全性。
那么refresh token是怎么给到应用方的呢？答案是在用户完成授权时，随 access token 一起重定向到回调 url，传递给应用方。
以上就是refresh token机制。
更多技术文章，请关注个人号：