OAuth 2.0 - Authorization Code受權方式詳解

I:OAuth 2.0 開發前期準備

天上不會天然掉餡餅讓你輕鬆地去訪問到人家資源服務器裏面的用戶數據資源，因此你須要作的前期開發準備工做就是把AppKey, AppSecret取到手 新浪獲取傳送門 ，騰訊獲取傳送門

這裏說一下，在申請AppKey和AppSecret的過程當中，新浪和騰訊的申請作法是有區別的。

在新浪微博的AppKey,AppSecret申請時會驗證你是否擁有域名的全部權 

而騰訊在這一塊上面則沒有這個要求！

PS：申請成爲開放平臺開發者時須要上傳身份證電子文件。。。。。

II:爲何不用官方提供的SDK

說到這個我就想吐槽了，這官方的SDK尼瑪的明顯排斥堆擠咋們作.net的啊！~~~ 
先上 新浪支持的SDK : 


而後在上 騰訊支持的SDK : 

文檔資料不全不說，出了問題你還得找人家。因此在這裏我也試想過轉戰JS SDK看看~因而又有了以下的悲劇事情發生：

騰訊和新浪的JS SDK都是主推用js彈窗方面的。這樣不太會電腦的用戶使用起來的話，就會以爲你的這個第三方應用會不會是病毒神馬的。 

IE9下彈窗提示 

Chrome下也會提示，因此這個東西是瀏覽器自己機制的問題~因此在 帖子 裏面也獲得了準確的答覆。 

稍微設置一下容許彈窗的話就獲得上面這個怪異摸樣。。。 

而在這裏稍微說一下騰訊的OPENJS這個東西！！我我的感受它想挑戰一下咱們開發人員的智商。。。 

這個爲何瀏覽器沒有阻止，徹底是在同域的狀況下啊~~~TX你這互聯老大連另外整個相似於新浪的獨立域名的工做都沒作好啊！！還在自家的API文檔站上高亮標示起這個OpenJS新秀呀。 
 

不過相比新浪的JS SDK騰訊自家的OpenJS的技術支持作得很是好的。你只要碰到了問題。都有人在線幫你解答。

PS:若是你選用JS SDK的話，那麼你的業務邏輯將會以js腳本的形式暴露在客戶端瀏覽器之下。

III:Authorization Code驗證受權模式

基礎知識： 
在這裏先引用前一篇文章裏的示例用圖，而後再接着講解各個部分的相關知識。 

1.Resource Server(資源服務器):負責存放服務提供商的用戶數據資源等相關信息。當第三方應用訪問這個資源服務器時，須要提供Access Token不然會提示訪問失敗。因此咱們最終的目的就是讓本身開發的第三方Web應用順利地訪問到服務提供商的資源服務器，這纔是這個系列文章的最終目的。

2.Authorization Server(驗證受權服務器):負責驗證用戶帳戶名密碼，以及給第三方WEB應用發放Access Token。在這裏我上傳兩張圖片爲你敘述Authorization Server是什麼樣子。 
新浪的Authorization Server 


騰訊的Authorization Server

接下來將會繼續講解，這個重要的Access Token(訪問令牌)究竟是怎麼取得的。 

首先做爲第三方網站上會顯示一個跳轉到新浪，騰訊受權服務器的<a />超級連接。以下圖： 


下面的圖片將介紹這兩個連接的跳轉地址規範： 


新浪的規範 
https://api.weibo.com/oauth2/authorize?client_id={AppKey}&response_type=code&redirect_uri={YourSiteUrl} 

騰訊的規範 
https://open.t.qq.com/cgi-bin/oauth2/authorize?client_id={AppKey}&response_type=code&redirect_uri={YourSiteUrl}

能夠看出新浪和騰訊的規範在此步驟基本一致。

如今講述第2步：

這時Authorization Server將會跳轉回申請受權驗證的第三方網站~可是會在QueryString內加上一個名爲code的參數！例子以下： 

騰訊:http://www.mytestsite.com/Tencent.aspx?code=174256357036c9df7db17342f15a9476&openid=45CD8A7A05A0C3E30D8A9AB74EEAA8D1&openkey=98B2964245A2BE2830F7A793E09FE6B0 
新浪:http://www.mytestsite.com/Sina.aspx?code=19b83321705c538e0422ba09ac9043a0

從這一步能夠看出企鵝與標準脫離的野心逐漸浮現。。。它不只僅返回code並且還參雜openid&openkey~不知在各位開發者的眼裏會不會以爲比較另類？

當咱們拿到跳轉回來Url上的QueryString參數code後就能夠再次去Authorization Server上請求獲取AccessToken這個重要令牌了！下面接着上圖！！！ 

具體說一下第3步的請求地址規範： 
新浪：https://api.weibo.com/oauth2/access_token?client_id={AppKey}&client_secret={AppSecret}&grant_type=authorization_code&redirect_uri={YourSiteUrl}&code={code} 
騰訊：https://open.t.qq.com/cgi-bin/oauth2/access_token?client_id={AppKey}&client_secret={AppSecret}&redirect_uri={YourSiteUrl}&grant_type=authorization_code&code={code}

在這一步，騰訊和新浪雙方都徹底保持一致，很是慶幸！

第4步，重點來了，受權服務器即將返回Access Token。這是以Response Body的方式，因此說Authorization Code受權方式並無對客戶端暴露AccessToken訪問令牌。也是我極力推薦使用的一種受權方式。 

上圖是新浪返回Access Token的內容 

上圖是騰訊返回Access Token的內容

這裏須要注意一下第3，4步必需要以http post的方式去發起Request。~

IV:總結

 

此文由nopcommerce羣友整理，在此供我的記錄與分享