oauth 2.0

I:OAuth 2.0 開發前期準備

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

這裏說一下,在申請AppKey和AppSecret的過程中,新浪和騰訊的申請做法是有區別的。image
在新浪微博的AppKey,AppSecret申請時會驗證你是否擁有域名的所有權    


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

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

II:爲什麼不用官方提供的SDK

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


然後在上騰訊支持的SDK:    
image    
image

文檔資料不全不說,出了問題你還得找人家。所以在這裏我也試想過轉戰JS SDK看看~於是又有了如下的悲劇事情發生:

騰訊和新浪的JS SDK都是主推用js彈窗方面的。這樣不太會電腦的用戶使用起來的話,就會覺得你的這個第三方應用會不會是病毒神馬的。   
image IE9下彈窗提示    


image Chrome下也會提示,所以這個東西是瀏覽器本身機制的問題~所以在帖子裏面也得到了準確的答覆。    


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


而在這裏稍微說一下騰訊的OPENJS這個東西!!我個人感覺它想挑戰一下我們開發人員的智商。。。    
image這個爲什麼瀏覽器沒有阻止,完全是在同域的情況下啊~~~TX你這互聯老大連另外整個類似於新浪的獨立域名的工作都沒做好啊!!還在自家的API文檔站上高亮標示起這個OpenJS新秀呀。    
image 

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

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

III:Authorization Code驗證授權模式

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

1.Resource Server(資源服務器):負責存放服務提供商的用戶數據資源等相關信息。當第三方應用訪問這個資源服務器時,需要提供Access Token否則會提示訪問失敗。所以我們最終的目的就是讓自己開發的第三方Web應用順利地訪問到服務提供商的資源服務器,這纔是這個系列文章的最終目的。

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


image    
騰訊的Authorization Server

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

首先作爲第三方網站上會顯示一個跳轉到新浪,騰訊授權服務器的<a />超級鏈接。如下圖:    
image    


下面的圖片將介紹這兩個鏈接的跳轉地址規範:    
image    

新浪的規範    
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步:image    


這時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這個重要令牌了!下面接着上圖!!!   
image

具體說一下第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訪問令牌。也是我極力推薦使用的一種授權方式。   
image    
image    
上圖是新浪返回Access Token的內容    


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

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

IV:總結

image

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章