Oauth2.0（二）：開放平臺

　　上一節說到Oauth2.0 的交互模型。模型涉及到三方：資源擁有者、客戶端、服務提供方。其中，服務提供方包含兩個角色：鑑權服務器和資源服務器。鑑權服務器負責對用戶進行認證，並受權給客戶端權限。認證這一步好實現，無非就是驗一下帳號密碼。可是受權這一步怎麼作？能夠看到在QQ的受權頁面上，有」有道雲筆記將得到如下權限「的字樣以及權限信息。鑑權服務器須要知道請求受權的客戶端的身份以及該客戶端請求的權限。因此，須要在談完合做以後，爲每個客戶端預先分配一個 id，並給每一個 id 對應一個名稱以及權限信息。這些信息能夠寫在鑑權服務器上的配置文件裏。而後，客戶端每次打開鑑權頁面的時候，把屬於本身的 id 傳過來，像這樣：

　　http://xxx.xxx.com/oauthPage?client_id=xxx

　　鑑權服務器就能夠根據這個 id 去展現受權信息了。

　　這個流程是 ok 的。可是，隨着時間的推移和業務的增加，會發現，修改配置的工做消耗了太多的人力。有沒有辦法把這個過程自動化起來，把人工從這些繁瑣的操做中解放出來？當開始考慮這一步，開放平臺的成型也就是水到渠成的事情了。

　　開放平臺是由 Oauth2.0 協議衍生出來的一個產品。它的做用是讓客戶端本身去這上面進行註冊、申請，經過以後系統自動分配 client_id ，並完成配置的自動更新（一般不是配置文件，而是寫進數據庫）。

　　開放平臺的一個實例：http://open.weibo.com/

　　客戶端要完成申請，一般須要填寫客戶端程序的類型（web、移動端app等）、企業介紹、執照、想要獲取的權限等等信息。這些信息在獲得服務提供方的人工審覈經過後，開發平臺就會自動分配一個 client_id 給客戶端了。

　　到這裏，已經實現了登陸認證、鑑權頁的信息展現。那麼接下來，當用戶成功進行受權以後，鑑權服務器須要把產生的 access token 發送給客戶端。這一步，怎麼作？

　　方案是這樣的：讓客戶端在開放平臺申請的時候，填寫一個 url，例如：

　　http://www.abc.com

　　而後。每次當有用戶受權成功以後，鑑權服務器將頁面重定向到這個 url ，並帶上 access token。這一步叫作回調。例如：

　　http://www.abc.com?accesstoken=xxxxxxxx

　　這樣，客戶端就接收到了這個 access token，並且鑑權服務器的受權動做已經完成，恰好能夠把程序的控制權轉交回客戶端，由客戶端決定接下來向用戶展現什麼內容。