上一節介紹過什么是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很少用於傳輸，所以它是安全的。