上一节介绍过什么是OAuth2，这节准备用生动的事例来告诉大家OAuth2运行的流程。
我们来想这样一个场景：假设我们有一个叫做万方网盘的服务是用来帮助用户存储论文文档的，我们向外提供了符合OAuth2标准的APi，可以让第三方程序获取到用户的论文。有一个第三方的程序可以调用我们平台的接口获取用户论文，来帮助用户投稿。
在OAuth中，我们管用户叫做资源拥有者（Resource Owner，RO），投稿应用叫做Client，万方网盘叫做资源服务（Resource Server，RS），昨天我们还提到的一个发放令牌的角色叫做授权服务（Authorization Server，AS）。
以下是OAuth2的基本运行流程：
0、Resource Owner向Cilent发出某个请求，这个请求需要调用Resource Owner的用户资源。
1、Client为了能够拿到用户的资源，就要先获取用户的授权。
2、client拿着用户授权向Authorization Server请求访问令牌（Access Token）
3、然后client再拿着访问令牌去向Resource Server获取用户资源
这就是一个完整的OAuth流程，放一张官方的图给大家看：
其实当第一次完成A到D的四个步骤之后，client再要去请求资源的时候，就直接拿着Access Token去请求就可以了，不需要每次都进行A到D四个步骤。因此，我们发现在这个过程中Access Token会经常的被传输，越是经常被网络传输的信息就越容易泄漏，因此Access Token的有效时间就要设置的短一些。但是如果因为Access Token的有效期短，导致了频繁向用户请求授权，这是一件用户体验很差的事情，为了解决这个问题，OAuth2引入了Refresh Token。
当Client得到用户授权之后，向授权服务器获取授权的时候，授权服务器不止会给Client一个Access Token还会给一个Refresh Token用以换取新的Access Token。当Client请求资源服务器之后，发现原本合法的Access Token失效之后（步骤E到F），会用Refresh Token向授权服务器再请求一个新的Access Token，授权服务器会将新的Access Token和新的Refresh Token发送给Client（步骤G到H）。由于有了Refresh Token，Client在向授权服务器请求Access Token的时候就可以不需要再次向用户请求授权了。同样的，因为Refresh Token很少用于传输，所以它是安全的。