Oauth2.0（二）：開放平臺

在上一篇文章《Oauth2.0（一）：爲何須要 Oauth2.0 協議？》中，提到Oauth2.0的交互模型以下：

這個模型涉及到三方：資源擁有者（用戶）、應用方（A）、服務提供方（B）。其中，服務提供方包含兩個角色：鑑權服務器和資源服務器。鑑權服務器負責對用戶進行認證，並受權給應用方權限。認證這一步好實現，無非就是驗一下帳號密碼。可是受權這一步怎麼作？這裏參考QQ受權給有道的頁面：

能夠看到在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，並且鑑權服務器的受權動做已經完成，恰好能夠把程序的控制權轉交回應用方，由應用方決定接下來向用戶展現什麼內容。

更多技術文章，請關注我的號：