Dev Guide: js | css | HTML(DOM) WEBCAST .NET4 Lib Web.config-WCF MVC3-EF4.1 T-SQL-(2012)

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的內容