2011年10月5日

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 的人,先做好心裡準備