如果我理解正確的話,從我的桌面應用程序調用API(姑且稱之爲從現在開始和「客戶」作爲了OAuth2標準上)我需要獲得的access_token它是結合了應用程序ID和標識用戶,誰是我想訪問的數據,id('資源所有者')。使用redirect_uri的Facebook客戶端身份驗證流程是否爲borken?
繼認證指南(developers.facebook.com/docs/authentication/)我明白,我需要發送請求到h客戶端流量** PS://www.facebook.com/dialog/oauth的client_id = YOUR_APP_ID & REDIRECT_URI = HTTP:// example.com & response_type = token。結果,該頁面將被重定向到h ** p://example.com/#access_token=XXX。如果客戶端是純桌面應用程序,那麼redirect_uri可以是h ** p://www.facebook.com/connect/login_success.html。由於客戶端擁有Web控件,因此可以輕鬆地從重定向的地址提取access_token。
客戶端側流由3個OAuth的步驟:
- 用戶認證,如果資源所有者沒有在給Facebook,對話記錄,要求對於Facebook憑證,將被顯示。如果資源所有者已登錄,則會話將使用Facebook服務器上的cookie進行身份驗證。安全 - 檢查V!
- 應用程序的授權,如果資源擁有者沒有給應用程序的權限呢,權限對話框會要求從資源所有者授予權限的應用程序,如果資源擁有者之前磨碎所有需要的權限,權限對話框不會被顯示。安全 - 檢查V!
- 應用程序身份驗證 - 現在,這裏是粘滯的地方。該指南說:「通過驗證redirect_uri與開發者應用程序中配置的站點URL位於相同的域中來處理應用程序身份驗證」。安全 - 在我看來 - 失敗!
爲什麼我認爲,最後一步是安全失敗?首先,app id和redirect_uri都是公共信息,任何人都可以獲得。其次,redirect_uri可以是h ** p://www.facebook.com/connect/login_success.html。
讓我們看看下面的場景。桌面應用程序EVE向用戶顯示一個Web控件,用戶登錄Facebook並授予EVE一些基本權限。資源所有者沒有理由懷疑任何事情。接着,EVE隱藏了網絡控制,並試圖在其上ħ** PS加載://www.facebook.com/dialog/oauth CLIENT_ID = OTHER_APP_ID & REDIRECT_URI = HTTP://www.facebook.com/ connect/login_success.html & response_type = token。該應用程序可以嘗試使用最流行的Facebook應用程序ID加載此網址。如果用戶以前授權OTHER_APP,該應用將獲得成功消息,因爲登錄對話框和權限對話框將不會顯示。這將使EVE獲得一個access_token來訪問資源所有者授予OTHER_APP而不是EVE的所有資源。
所以,這是一個安全漏洞?我錯過了後續的東西嗎?
(UPDATE)在一個桌面應用程序的情況下
顯然,安全問題是無關緊要的,因爲該應用程序已具有用戶名和facebook的會話,甚至用戶名和密碼,就可以做任何事情用戶帳戶。
(更新) 對於在Web瀏覽器中運行的JavaScript應用程序,redirect_uri實際上可行! (請參閱hnrt的回答和評論)。
當前的問題: 唯一剩下的祕密就是客戶端身份驗證如何在iPhone和Android應用上運行?整個安全性與使用桌面應用程序時的安全性是否相似?越獄iPhone或固定的Android有什麼不同?
乾杯!
至少在iPhone上,它看起來像每個令牌請求不同的app_id要求用戶登錄。什麼阻止開發人員不使用SDK,但通過標準API請求access_token? – fudge 2011-02-06 12:17:00