Facebook OAuth 2.0

我一直到10/1才注意到facebook要停止支援oauth 1.0，不過facebook並沒有按照時間表馬上停止對oauth 1.0 的支援，給了我一些緩衝的時間來了解。

OpenID vs. OAuth

OpenID是一個去中心化的身份辨別機制，任何網站都可以成為openid provider，而openid consumer 只要相信一個provider，就能夠使用使用者在這個provider上面的身份當作一個可信任的網路ID，常見的作法是在consumer端提供一個讓使用者填入porvider的認證uri，在provider端確認身份之後把身份拿給consumer端使用。我私自認為這只是要省掉一組帳號密碼的機制。

OAuth談的是授權，主要是讓使用者可以以此機制讓第三方服務在限制的時間和範圍(scope)內取得他在一個內容提供者儲存的資料，第三方服務藉由此內容提供者提供的access token來向內容提供者要求資料。

oauth 2.0相對於1.0的優點，這篇講得很清楚，一般開發大平台裡面的應用程式使用的是三方認證，在1.0中access token在傳送過程中如果是不加密的(plain HTTP)，雖然到server之後會用hmac sha1確認正確性，(而且facebook作法已經在固定時段之後會丟棄)，但是仍然有被sniff而資料外流的風險，oauth 2.0則是使用短週期的refresh token如 google 的 5 分鐘過期token，除此之外，oauth 2.0 簡化了client端的驗證手續，比如說在oauth 1.0中server和client必須確保變數有相同的順序加密，(facebook SDK作法也已經處理好了)，這樣才會得到一樣的signature，在oauth2.0中如果用client端認證，client拿到的是加密的code，直接將code交給server，server通過SSL訪問oauth authentication server來交換得到access token，之後的作法就一樣了。如果直接使用server端認證(在facebook裡面是signed_request)則沒有太大差別。

Facebook Javacript SDK 改用oauth 2.0注意事項

首先，oauth 1.0 和 2.0 是不相容的，勢必要有code change

client端FB.init()中要加上 oauth:true
如果用跳轉方式認證，facebook會提供code參數
如果用cookie認證，會得到名為fbsr_(app_id)內容是用app key 加密過的 code
將此code交給server
server 端 可以參考這裡的方式來處理cookie和code進而獲得access token

更改之後，一切才要開始
所有的FB開頭的function都要重新測試
大概只有FB.login()和FB.logout()可以信任
其他像是FB.ui()裡面會有一堆的bug
facebook對這些bug的態度相當消極
我遇到一些bug上去facebook bug tracker一看，早就開天窗開了六個月了bug還不修

也沒有任何時間上的承諾

所以要改用oauth 2.0 的人，先做好心裡準備