作者：Jakob Jenkov   譯者：林浩    校對：郭蕾

當一個客戶端應用想要訪問擁有者託管在資源伺服器的資源時，它必須先獲得授權，本節將講述客戶端如何獲取授權。

客戶端標識，客戶端金鑰和重定向URI

在客戶端應用能請求訪問資源伺服器的資源之前，客戶端應用程式，必須先在資源伺服器相關聯的授權伺服器中進行註冊。

註冊一個一次性的任務。一旦註冊了，除非客戶端註冊被取消了，註冊將持續有效。

註冊後客戶端應用將由授權伺服器分配客戶端標識和金鑰。在授權伺服器上，客戶端標識和金鑰是唯一標識客戶端應用的。如果客戶端應用註冊了多個授權伺服器(如Facebook, Twitter和Google等)，每一個授權伺服器將發出唯一的標識給該客戶端應用。

無論什麼時候客戶端應用，想要訪問同樣資源伺服器上的資源，它都需要通過傳送客戶端標識和金鑰到授權伺服器來驗證自己。

在註冊過程中，客戶端應用也註冊了一個重定向URI，當資源擁有者授權給客戶端應用時，該重定向URI會被使用。當資源擁有者成功的通過授權伺服器授權給客戶端應用時，資源擁有者被重定向回客戶端應用，再跳轉到該重定向URI。

• 授權批准

授權批准由資源伺服器，及與其相關的授權伺服器，給予客戶端應用。

OAuth 2.0列舉四種不同型別授權批准，每一種型別都有不同的安全特性。這些授權批准型別為：

• 授權碼
• 契約
• 資源擁有者金鑰證書
• 客戶端證書

每種授權批准在下文都會提到。

授權碼

用授權碼來授權批准原理如下：資源擁有者(使用者)訪問客戶端應用。客戶端應用告訴使用者通過授權伺服器(如Facebook, Google和Twitter等)來登入到客戶端應用。

為了通過授權伺服器登入，使用者通過客戶端應用被重定向到授權伺服器。客戶端應用傳送它的客戶端標識給授權伺服器，那麼授權伺服器就知道是哪個應用嘗試訪問受保護的資源。當被重定向回客戶端應用時，授權伺服器傳送給使用者特定的重定向URI,  即客戶端已經提前與授權伺服器註冊。隨著重定向，授權伺服器傳送一個代表授權的授權碼。

當在客戶端應用的重定向URI被訪問時，客戶端應用直接連線授權伺服器。客戶端應用傳送授權碼，客戶端標識及金鑰，如果客戶端應用能接受這些值，那麼授權伺服器返回一個訪問令牌。

現在客戶端應用就可以用該訪問令牌請求資源伺服器的資源了。該訪問令牌可作為客戶端授權和授權訪問資源。

下面是當用授權碼授權客戶端應用時的授權過程：

通過授權碼授權

契約

契約授權類似於授權碼授權，除了使用者完成授權後，訪問令牌返回給客戶端應用外。當用戶代理被重定向到重定向URI時，訪問令牌因此被返回。

當然這意味著訪問令牌可以被使用者代理訪問，或者在契約授權過程中參與的原生應用。訪問令牌在web伺服器上不是安全儲存的。

進一步說，客戶端應用可以只發送它的客戶端標識給授權伺服器。如果客戶端也傳送它的金鑰，那麼客戶端金鑰將不得不儲存在使用者代理或原生應用裡，那將使它很容易被破解。

契約授權大多數用在使用者代理或原生應用中。使用者代理或原生應用將收到來授權伺服器的訪問令牌。

下面是闡釋契約授權的圖：

契約授權

資源擁有者金鑰證書

資源擁有者證書授權方法通過客戶端應用訪問資源擁有者證書來工作。比如，使用者可以在客戶端應用輸入他的Twitter使用者名稱及金鑰(證書)。該客戶端應用就可以用著使用者名稱和金鑰訪問使用者在Twitter的資源。

用資源擁有者金鑰證書要求客戶端應用很多信任。你不想在那些你懷疑會濫用證書的客戶端應用中輸入證書。

資源擁有者金鑰證書通常被用在使用者代理或原生應用中。

客戶端證書

客戶端證書授權對於客戶端需要在資源伺服器訪問資源或呼叫函式的情形使用，與特定的資源擁有者無關(如使用者)。比如，從Foursquare獲取場地列表，這並沒有必要通過某個Foursquare使用者才能做。