理解OAuth 2.0

目錄：
    * 名詞定義
    * OAuth的思路
    * 運行流程
    * 客戶端的四種受權模式

1、名詞定義

（1） Third-party application：第三方應用程序，本文中又稱」客戶端」（client）。
（2）Resource Owner：資源全部者，本文中又稱」用戶」（user）。
（3）User Agent：用戶代理，指瀏覽器、APP等。
（4）Authorization server：認證服務器，即服務提供商專門用來處理認證的服務器。
（5）Resource server：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，能夠是同一臺服務器，也能夠是不一樣的服務器。

2、OAuth的思路

    OAuth在"客戶端"與"服務提供商"之間，設置了一個受權層（authorization layer）。"客戶端"不能直接登陸"服務提供商"，只能登陸受權層，以此將用戶與客戶端區分開來。"客戶端"登陸受權層所用的令牌（token），與用戶的密碼不一樣。用戶能夠在登陸的時候，指定受權層令牌的權限範圍和有效期。

"客戶端"登陸受權層之後，"服務提供商"根據令牌的權限範圍和有效期，向"客戶端"開放用戶儲存的資料。

3、運行流程

   OAuth 2.0 的運行流程以下圖，摘自RFC 6749。

（A）受權請求。用戶打開客戶端終端（web or APP）之後，客戶端要求用戶給予受權。這個受權請求能夠直接提交給資源全部者。（如圖所示），或最好是間接經過受權層做爲中介進行受權。
（B）用戶受權。客戶端收到了一個來自用戶的受權憑證。這個憑證，能夠經過四種方式來獲取，至於哪四種，下面有介紹。
（C）請求認證服務器受權。客戶端使用上面用戶受權獲得的憑證向認證服務器請求一個擁有特定訪問權限的訪問令牌（access token），注意，access token 是和權限綁定的。
（D）發放令牌。認證服務器向客戶端發放客戶端在上一步請求的令牌。
（E）請求資源。客戶端使用訪問令牌向資源服務器請求用戶的受保護的資源。
（F）返回資源。資源服務器驗證訪問令牌是否有效，有效則返回請求的資源。如何判斷是否有效呢，固然是調用認證服務器的準備好的服務了。

 上面六個步驟之中，B是關鍵，即用戶怎樣才能給於客戶端受權。有了這個受權之後，客戶端就能夠獲取令牌，進而憑令牌獲取資源。

4、客戶端的四種受權模式

客戶端必須獲得用戶的受權（authorization grant），才能得到令牌（access token）。OAuth 2.0 定義了四種受權模式。

* 受權碼模式（authorization code）
* 簡化模式（implicit）
* 密碼模式（resource owner password credentials）
* 客戶端模式（client credentials）

1. 受權碼模式

    它的特色就是經過客戶端的後臺服務器，與」服務提供商」的認證服務器進行互動。受權碼受權方式用於同時獲取 accessToken 和 refreshToken，並對信任的客戶端進行了優化。因爲這是一個基於重定向的流程，client 必須能與 resource owner 的 user-agent（一般是瀏覽器）進行交互而且可以接收到 authorization server 經過重定向傳入的請求。

（A）客戶端將用戶瀏覽器引導向認證端。客戶端包含了客戶端標識 client_id，請求受權範圍 scope，本地狀態state，回調地址 redirect_uri，一旦被受權（或被拒絕），認證服務器將會把回調地址返回給瀏覽器。
（B）用戶操做受權，好比用戶進行選擇資源範圍，輸入密碼點肯定發送請求，決定是否給客戶端受權。
（C）認證服務器校驗用戶真實性，假設用戶給予受權，認證服務器將用戶導向客戶端事先指定的回調地址 redirect_uri，回調地址後面同時附上一個受權碼 code 和以前設置的 state （這裏的state，其實就是客戶端預留的，用以當受權成功後，執行某些事件等，好比能夠放一個js的方法名）。
（D）客戶端使用上一步返回的受權碼 code 附上以前用來獲取受權碼的回調地址 redirect_uri 向認證服務器請求一個訪問令牌 （access token）。這一步是在客戶端的後臺的服務器上完成的，對用戶不可見。
（E）認證服務器覈對了受權碼和重定向URI，和在（C）步驟中的兩個參數比對確認無誤後，向客戶端發送訪問令牌（access token）和可選的刷新令牌（refresh token）。

在這個流程裏面，有幾個關鍵的參數，client_id，redirect_uri，code，access token，refresh token，下面簡單解釋一下。

client_id：客戶端id。這個是認證端預先分配給客戶端的。好比說，你要使用QQ登陸新浪，那麼新浪確定是須要在QQ的認證中心備案的，而後 QQ 給新浪一個client_id，可能還有個secret，而後在約定一個回調地址 redirect_uri。而後新浪才能調用 QQ 的受權頁面展現給用戶看，讓用戶受權。

redirect_uri：回調地址。當你在QQ頁面上受權完了，就會跳轉到這個URI，就是受權成功後執行一些什麼操做。若是沒有這玩意的話，當你受權完了，而後呢，新浪也不知道接下來應該幹嗎。

code：爲何要使用code呢？由於安全，這樣，user agent 端只會出現code，正常狀況下不會存在access token 和 refresh token，access token 和 refresh token只會在客戶端即第三方的服務端和資源所在的服務器端流通。每每，客戶端（user agent）被認爲是不安全的，因此要儘可能把重要的信息存在服務器端，以防止被篡改使用。

access token：即訪問令牌。訪問令牌用來訪問資源信息，它自己就是權限，用戶不可見。訪問令牌的出現，可讓用戶自主設定一個權限範圍，也有了隨時取消第三方權限的方式。它還有時效性，一般在返回該令牌的時候，也會隨之返回一個有效時間，幾十分鐘到幾十天不等，看認證服務器端的設置。OAuth 1.0 的時候，accessToken 是沒有時間限制的，就是永久有效，這樣的話，那第三方就能一直使用該令牌獲取用戶的資源，那若是用戶好幾個月都沒有登陸認證服務器設置，或者是忘記了，那麼第三方就能永遠能夠訪問，不太好，因此，在OAuth 2.0 的時候，增長了 refresh token。

refresh token：用途，看字面意思就知道，刷新令牌，當 access token 過時以後刷新出新的 access token。那就與上面的說法又矛盾了，這樣一來的話，那不就是說能夠一直使用 refresh token 來刷新出有效的 access token，這不就是變相的能夠永久訪問嗎？確實，這是一個問題，因此，通常， refresh token 也是有時效性的，有過時時間，甚至，好多公司直接去掉了 refresh token ，僅僅返回有必定時間限制的 access token。那 refresh token 的存在乎義又在哪裏呢，應該是：有了它，能夠改變 access token 的屬性而不用再次經歷受權。好比更改 accessToken 的權限的時候，只要使用 refresh token來刷新一個新的就行了，而不用再輸入密碼什麼的。

2. 簡化模式

簡化模式（implicit grant type）不經過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了"受權碼"這個步驟，所以得名。全部步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不須要認證。

（A）客戶端將用戶導向認證服務器。
（B）用戶決定是否給於客戶端受權。
（C）假設用戶給予受權，認證服務器將用戶導向客戶端指定的"重定向URI"，並在URI的Hash部分包含了訪問令牌。
（D）瀏覽器向資源服務器發出請求，其中不包括上一步收到的Hash值。
（E）資源服務器返回一個網頁，其中包含的代碼能夠獲取Hash值中的令牌。
（F）瀏覽器執行上一步得到的腳本，提取出令牌。
（G）瀏覽器將令牌發給客戶端。

3.密碼模式

    密碼模式（Resource Owner Password Credentials Grant）中，用戶向客戶端提供本身的用戶名和密碼。客戶端使用這些信息，向"服務商提供商"索要受權。

在這種模式中，用戶必須把本身的密碼給客戶端，可是客戶端不得儲存密碼。這一般用在用戶對客戶端高度信任的狀況下，好比客戶端是操做系統的一部分，或者由一個著名公司出品。而認證服務器只有在其餘受權模式沒法執行的狀況下，才能考慮使用這種模式。

（A）用戶向客戶端提供用戶名和密碼。
（B）客戶端將用戶名和密碼發給認證服務器，向後者請求令牌。
（C）認證服務器確認無誤後，向客戶端提供訪問令牌。

4.客戶端模式

    客戶端模式（Client Credentials Grant）指客戶端以本身的名義，而不是以用戶的名義，向"服務提供商"進行認證。嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。在這種模式中，用戶直接向客戶端註冊，客戶端以本身的名義要求"服務提供商"提供服務，其實不存在受權問題。

（A）客戶端向認證服務器進行身份認證，並要求一個訪問令牌。
（B）認證服務器確認無誤後，向客戶端提供訪問令牌。