微信公共服務平臺開發（.Net 的實現）12-------網頁受權（上 ：更加深刻理解OAuth2.0 ）

咱們首先來認識一下OAuth協議吧，這個東西很早就據說過，總以爲離我很遠（個人項目用不到這些），可是最近不得不學習一下了。我在網上找了一些解釋，認爲解釋的最好的是這樣說的（出處：http://hi.baidu.com/powerthinks/item/f1cb9b3c7a88251c9dc65efa）

     若是你開車去酒店赴宴，你常常會苦於找不到停車位而耽誤不少時間。是否有好辦法能夠避免這個問題呢？有的，據說有一些豪車的車主就不擔憂這個問題。豪車通常配備兩種鑰匙：主鑰匙和泊車鑰匙。當你到酒店後，只須要將泊車鑰匙交給服務生，停車的事情就由服務生去處理。與主鑰匙相比，這種泊車鑰匙的使用功能是受限制的：它只能啓動發動機並讓車行駛一段有限的距離，能夠鎖車，但沒法打開後備箱，沒法使用車內其餘設備。這裏就體現了一種簡單的「開放受權」思想：經過一把泊車鑰匙，車主便能將汽車的部分使用功能（如啓動發動機、行駛一段有限的距離）受權給服務生。

    受權是一個古老的概念，它是一個多用戶系統必須支持的功能特性。好比，Alice和Bob都是Google的用戶，那麼Alice應該能夠將本身的照片受權給Bob訪問。但請注意到，這種受權是一種封閉受權，它只支持系統內部用戶之間的相互受權，而不能支持與其餘外部系統或用戶之間的受權。好比說，Alice想使用「網易印像服務」將她的部分照片沖印出來，她怎麼能作到呢？

確定有人會說，Alice能夠將本身的Google用戶名和密碼告訴網易印像服務，事情不就解決了嗎？是的，但只有絕不關注安全和隱私的同窗纔會出此「絕招」。那麼咱們就來想想，這一「絕招」存在哪些問題？

(1) 網易印像服務可能會緩存Alice的用戶名和密碼，並且可能沒有加密保護。它一旦遭到攻擊，Alice就會躺着中槍。

(2) 網易印像服務能夠訪問Alice在Google上的全部資源，Alice沒法對他們進行最小的權限控制，好比只容許訪問某一張照片，1小時內訪問有效。

(3) Alice沒法撤消她的單個受權，除非Alice更新密碼。

在以Web服務爲核心的雲計算時代，像用戶Alice的這種受權需求變得日益迫切與興盛，「開放受權(Open Authorization)」也正所以而生，意在幫助Alice將她的資源受權給第三方應用，支持細粒度的權限控制，而且不會泄漏Alice的密碼或其它認證憑據。

  

上面的例子寫的通俗易懂，各位一看就明白了，後面做者還附了一個這樣圖，以及註釋：

 

從引言部分的描述咱們能夠看出，OAuth的參與實體至少有以下三個：

· RO (resourceowner): 資源全部者，對資源具備受權能力的人。如上文中的用戶Alice。

· RS (resourceserver): 資源服務器，它存儲資源，並處理對資源的訪問請求。如Google資源服務器，它所保管的資源就是用戶Alice的照片。

· Client: 第三方應用，它得到RO的受權後即可以去訪問RO的資源。如網易印像服務。

此外，爲了支持開放受權功能以及更好地描述開放受權協議，OAuth引入了第四個參與實體：

· AS(authorization server): 受權服務器，它認證RO的身份，爲RO提供受權審批流程，並最終頒發受權令牌(Access Token)。讀者請注意，爲了便於協議的描述，這裏只是在邏輯上把AS與RS區分開來；在物理上，AS與RS的功能能夠由同一個服務器來提供服務。

 

如圖1所示，協議的基本流程以下：

(1) Client請求RO的受權，請求中通常包含：要訪問的資源路徑，操做類型，Client的身份等信息。

(2) RO批准受權，並將「受權證據」發送給Client。至於RO如何批准，這個是協議以外的事情。典型的作法是，AS提供受權審批界面，讓RO顯式批准。這個能夠參考下一節實例化分析中的描述。

(3) Client向AS請求「訪問令牌(AccessToken)」。此時，Client需向AS提供RO的「受權證據」，以及Client本身身份的憑證。

(4) AS驗證經過後，向Client返回「訪問令牌」。訪問令牌也有多種類型，若爲bearer類型，那麼誰持有訪問令牌，誰就能訪問資源。

(5) Client攜帶「訪問令牌」訪問RS上的資源。在令牌的有效期內，Client能夠屢次攜帶令牌去訪問資源。

(6) RS驗證令牌的有效性，好比是否僞造、是否越權、是否過時，驗證經過後，才能提供服務。

 

雖然上面的例子舉的很好，圖畫的也很清楚，但是對於我這種愚鈍的人，仍是理解了半天，請容許我在此狗尾續貂一次吧：

其實上面的圖就如同這樣一個故事

一、個人一個同事小張（Client），向我或者公司（RO）借錢，他會給我說：「借給我2000元，能夠嗎？」（也就是說向我請求一個有限的資源，就是Authorization Request）；

二、這時我確定不會把個人銀行卡給他，並告訴他密碼，我要用到OAuth。首先我會說「好的」，而且給他寫一個條，上面寫着「容許小張借款2000元」的請求（Authorization Grant）；

三、小張拿着我寫的條（AuthorizationGrant），給財務總監（AS）；

四、財務總監看到個人條後會給小張一個提款單（Access Token），上面寫着請出納給小張支出2000元的借款。

五、小張拿到了提款單（AccessToken）到出納那裏，按照公司的規定，出納只有看到了財務總監給的提款單（Access Token），才能過支出錢，這是出納覈對後，小張就順利的拿到了2000元錢（Protected Resource）。

 

根據上面的故事咱們來講已說OAuth的特色：

一、小張不可能知道，我或者公司總共有多少錢；

二、我也保護了帳戶的密碼，維護的公司的制度；

三、就像現實中同樣，財務總監和出納通常都在一塊兒辦公，而AS和RS通常也會在同一個服務器上；

四、按照一樣的公司制度（也就是OAuth），其餘人無論誰來支出錢都要這樣，我只須要保證制度執行的嚴密，其餘任何人都不會知道個人賬務信息了。

這也就是OAuth全稱--- OpenAuthorization（開放式受權）的意義了。

 

下面我來看看爲微信中是如何實現這個過程的，我引用了方倍工做室教程裏面的圖（http://www.cnblogs.com/txw1958/p/weixin71-oauth20.html）：

 

 

在這個途中User就是我例子中的小張，APP就是我，Auth_svr就是財務總監和出納。

若是我使用微信中的官法提法因該這麼說：

一、小張向我提出訪問，訪問過程涉及如下參數：

 

   也就是要知道個人APPID：其實就是個人名字；redirect_uri：到財務那裏怎麼走；response_type：知道我想我要批條（請填寫code）；scope批條的類別（後面會介紹到）；state：到財務那裏帶些什麼（參數）。

 

二、我贊成了他的要求

  也就是微信幫助提到的「若是用戶贊成受權，頁面將跳轉至 redirect_uri/?code=CODE&state=STATE。」也就是我給了小張一個批條（code），告訴小張去財務的路，以及到那裏須要帶些什麼。

 

三、小張拿着個人批條到財務總監那裏獲得提款單

小張拿着個人批條（code），按照「redirect_uri/?code=CODE&state=STATE」這個路徑去財務那裏「經過code換取網頁受權access_token」

 

上圖能夠知道我還能夠得到OPENID！這個是很是重要的，前一章提到了它的用處，微信在這裏還特別強調了「獲取用戶基本信息接口是在用戶和公衆號產生消息交互時，才能根據用戶OpenID獲取用戶基本信息，而網頁受權的方式獲取用戶基本信息，則無需消息交互，只是用戶進入到公衆號的網頁，就可彈出請求用戶受權的界面，用戶受權後，就可得到其基本信息（此過程甚至不須要用戶已經關注公衆號。）」

 

四、小張拿到了提款單又到出納那裏提款

獲得了access_token後，拉取用戶信息，也就是「經過access_token和openid拉取用戶信息了。」

 

最終獲得是以下的信息：

 

 

原本就此已經說完了，不過很多研發人員可能仍是會有疑問：「費這麼半天勁，不就獲得了個用戶的基本信息嘛，我經過其餘方式也能夠獲得！」。

其實否則，這仍是很是有用的：

第一，這是惟一一個重不須要關注你的微信好就可得到用戶信息的辦法；

第二，咱們來設想一下下面場景：若是咱們開發一個系統想過沒想過不要用戶名和密碼了？用戶登陸，並受權之後，進入咱們的系統，我係統裏面存放着這個微信號（OPENID）對應的權限的功能。這樣我不再用擔憂用戶忘記密碼或者密碼泄露的事情了，由於這些事情微信已經幫助給作了。說到這裏可能你還會問：「那豈不是每一個人必須有微信號」，我先不說這裏咱們作的就是微信平臺的應用，也不說騰訊有多大的野心，這種OAuth協議已經在微博，google，baidu，郵箱等普遍應用，我作他們響應的接口，你就說一個上用你係統的人，沒有微信還不能有微博，google，baidu這些賬號，沒有這些賬號你還能沒有個郵箱？這些我以爲因該是之後的趨勢。

況且，隨着微信的完善，之後或許咱們拿到的不只是用戶的基本信息，還有用戶朋友圈的帖子，圖片，用戶的喜愛等等，這些都爲咱們新開發的系統提供了有效的可分析的數據！