OAuth2：Authorization Flows

Ref：http://www.dannysite.com/blog/176/

OAuth2.0協議定義了用於得到受權的四種主要受權類型。

1. Client Credentials

一種基於APP的密鑰直接進行受權，所以APP的權限很是大。它適合像數據庫或存儲服務器這種對API的訪問需求。

示例：

當初作Wish API的時候，Wish官方的受權直接給一個Token，訪問的時候直接傳token附帶在https請求中就能夠了。屬於Wish API 1.0 時代的產物。

2. Authorization code

標準的Server受權模式，很是適合Server端的Web應用。一旦資源的擁有者受權訪問他們的數據以後，他們將會被重定向到Web應用並在URL的查詢參數中附帶一個受權碼（code）。在客戶端裏，該code用於請求訪問令牌（access_token）。而且該令牌交換的過程是兩個服務端以前完成的，防止其餘人甚至是資源擁有者本人獲得該令牌。另外，在該受權模式下能夠經過refresh_token來刷新令牌以延長訪問受權時間。

示例：

Wish API 2.0後，就是使用此方式，填完用戶信息，要去AuthServer得到一個Code，而後根據Code再去拿一個Access Token。

• 1.https://merchant.wish.com/oauth/authorize?client_id={client_id}
• 2.https://localhost/authcode?code={authorization_code}
• 3.根據{authorization_code}，POST

POST https://merchant.wish.com/api/v2/oauth/access_token

Parameters
client_id   Your app's client ID
client_secret   Your app's client secret
code    The authorization code you received
grant_type  The string 'authorization_code'
redirect_uri    Your app's redirect uri that you specified when you created the app

• 4.訪問的時候，Authorization: Bearer {access_token}

POST https://merchant.wish.com/api/v2/auth_test

Parameters
access_token    Your access token

參考官方文檔：https://merchant.wish.com/documentation/oauth。

3. Implicit Grant

該模式是全部受權模式中最簡單的一種，併爲運行於瀏覽器中的腳本應用作了優化。當用戶訪問該應用時，服務端會當即生成一個新的訪問令牌（access_token）並經過URL的#hash段傳回客戶端。這時，客戶端就能夠利用JavaScript等將其取出而後請求API接口。該模式不須要受權碼（code），固然也不會提供refresh token以得到長期訪問的入口。

4. Resource Owner Password Credentials

這種模式要求用戶提供用戶名和密碼來交換訪問令牌（access_token）。該模式僅用於很是值得信任的用戶，例如API提供者本人所寫的移動應用。雖然用戶也要求提供密碼，但並不須要存儲在設備上。由於初始驗證以後，只需將OAuth的令牌記錄下來便可。若是用戶但願取消受權，由於其真實密碼並無被記錄，所以無需修改密碼就能夠當即取消受權。token自己也只是獲得有限的受權，所以相比最傳統的username/password受權，該模式依然更爲安全。