39
OAuth 2.0係列教程（五） 授權
當一個客戶端應用想要訪問擁有者托管在資源服務器的資源時，它必須先獲得授權，本節將講述客戶端如何獲取授權。
客戶端標識，客戶端密鑰和重定向URI
在客戶端應用能請求訪問資源服務器的資源之前，客戶端應用程序，必須先在資源服務器相關聯的授權服務器中進行注冊。
注冊一個一次性的任務。一旦注冊了，除非客戶端注冊被取消了，注冊將持續有效。
注冊後客戶端應用將由授權服務器分配客戶端標識和密鑰。在授權服務器上，客戶端標識和密鑰是唯一標識客戶端應用的。如果客戶端應用注冊了多個授權服務器(如Facebook, Twitter和Google等)，每一個授權服務器將發出唯一的標識給該客戶端應用。
無論什麼時候客戶端應用，想要訪問同樣資源服務器上的資源，它都需要通過發送客戶端標識和密鑰到授權服務器來驗證自己。
在注冊過程中，客戶端應用也注冊了一個重定向URI，當資源擁有者授權給客戶端應用時，該重定向URI會被使用。當資源擁有者成功的通過授權服務器授權給客戶端應用時，資源擁有者被重定向回客戶端應用，再跳轉到該重定向URI。
- 授權批準
授權批準由資源服務器，及與其相關的授權服務器，給予客戶端應用。
OAuth 2.0列舉四種不同類型授權批準，每一種類型都有不同的安全特性。這些授權批準類型為：
- 授權碼
- 契約
- 資源擁有者密鑰證書
- 客戶端證書
每種授權批準在下文都會提到。
授權碼
用授權碼來授權批準原理如下：資源擁有者(用戶)訪問客戶端應用。客戶端應用告訴用戶通過授權服務器(如Facebook, Google和Twitter等)來登錄到客戶端應用。
為了通過授權服務器登錄，用戶通過客戶端應用被重定向到授權服務器。客戶端應用發送它的客戶端標識給授權服務器，那麼授權服務器就知道是哪個應用嚐試訪問受保護的資源。當被重定向回客戶端應用時，授權服務器發送給用戶特定的重定向URI, 即客戶端已經提前與授權服務器注冊。隨著重定向，授權服務器發送一個代表授權的授權碼。
當在客戶端應用的重定向URI被訪問時，客戶端應用直接連接授權服務器。客戶端應用發送授權碼，客戶端標識及密鑰，如果客戶端應用能接受這些值，那麼授權服務器返回一個訪問令牌。
現在客戶端應用就可以用該訪問令牌請求資源服務器的資源了。該訪問令牌可作為客戶端授權和授權訪問資源。
下麵是當用授權碼授權客戶端應用時的授權過程：
通過授權碼授權
契約
契約授權類似於授權碼授權，除了用戶完成授權後，訪問令牌返回給客戶端應用外。當用戶代理被重定向到重定向URI時，訪問令牌因此被返回。
當然這意味著訪問令牌可以被用戶代理訪問，或者在契約授權過程中參與的原生應用。訪問令牌在web服務器上不是安全存儲的。
進一步說，客戶端應用可以隻發送它的客戶端標識給授權服務器。如果客戶端也發送它的密鑰，那麼客戶端密鑰將不得不保存在用戶代理或原生應用裏，那將使它很容易被破解。
契約授權大多數用在用戶代理或原生應用中。用戶代理或原生應用將收到來授權服務器的訪問令牌。
下麵是闡釋契約授權的圖：
契約授權
資源擁有者密鑰證書
資源擁有者證書授權方法通過客戶端應用訪問資源擁有者證書來工作。比如，用戶可以在客戶端應用輸入他的Twitter用戶名及密鑰(證書)。該客戶端應用就可以用著用戶名和密鑰訪問用戶在Twitter的資源。
用資源擁有者密鑰證書要求客戶端應用很多信任。你不想在那些你懷疑會濫用證書的客戶端應用中輸入證書。
資源擁有者密鑰證書通常被用在用戶代理或原生應用中。
客戶端證書
客戶端證書授權對於客戶端需要在資源服務器訪問資源或調用函數的情形使用，與特定的資源擁有者無關(如用戶)。比如，從Foursquare獲取場地列表，這並沒有必要通過某個Foursquare用戶才能做。
最後更新：2017-05-24 09:31:57