Oauth2.0（三）：Access Token 与 Refresh Token

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机制。

更多技术文章，请关注我的号：