的基本流程爲：
1、用戶訪問第三方應用。
2、第三方應用請求用戶授權。
3、用戶同意授權，並返回一個憑證（code）。
4、第三方應用通過第二步的憑證（code）向授權服務器請求授權。
5、授權服務器驗證憑證（code）通過後，同意授權，並返回一個資源訪問的憑證（Access Token）。
6、第三方應用通過第四步的憑證（Access Token）向資源服務器請求相關資源。
7、資源服務器驗證憑證（Access Token）通過後，將第三方應用請求的資源返回。
解釋：
在用戶授權這一步中，我們將得到一個用戶憑證（code），我們的應用可以通過該用戶憑證（code）來和授權服務器交換一個資源訪問憑證（Access Token）
當用戶點擊按鈕同意授權後，授權服務器將生成一個用戶憑證（code），此時授權服務器如何將用戶憑證（code）傳遞給第三方應用呢？
當我們向授權服務器提交應用信息時，通常需要填寫一個redirect_uri，當我們引導用戶進入授權頁面時，也會附帶一個redirect_uri的信息（如https://github.com/login/oauth/authorize?client_id=xxx&redirect_uri=http%3A%2F%2Ftianmaying.com%2Foauth%2Fgithub%2Fcallback&state=XXX），當授權服務器驗證兩個URL一致時，會通知瀏覽器跳轉到redirect_uri，同時，在redirect_uri後附加用戶憑證（code）的相關信息，此時，瀏覽器返回第三方應用同時攜帶用戶憑證（code）的相關信息。授權後訪問的redirect_uri如下：
http://tianmaying.com/oauth/github/callback?code=9e3efa6cea739f9aaab2&state=XXX
瀏覽器端的行爲實際上是不安全的，甚至安全憑證的傳遞都是通過URL直接傳遞的。但是由於用戶憑證（code）不是那麼敏感，其他攻擊者拿到用戶憑證（code）後依然無法獲取到相應的用戶資源，所以之前的行爲是允許的。
要拿到授權服務器的授權，需要以下幾個信息：
* client_id 標識第三方應用的id，由授權服務器（Github）在第三方應用提交時頒發給第三方應用
* client_secret 第三方應用和授權服務器之間的安全憑證，由授權服務器（Github）在第三方應用提交時頒發給第三方應用
* code 第一步中返回的用戶憑證redirect_uri 第一步生成用戶憑證後跳轉到第二步時的地址
* state 由第三方應用給出的隨機碼
我們看到，上述信息還涉及到第三方應用的安全憑證（client_secret），因此要求OAuth要求該請求必須時POST請求，同時，還必須時HTTPS服務，以此保證獲取到的驗證憑證（Access Token）的安全性。
拿到驗證憑證（Access Token）後，剩下的事情就很簡單了，資源服務器會提供一系列關於用戶資源的API，拿驗證憑證（Access Token）訪問相應的API即可
