我正在考慮Facebook登錄我的網站。基於基於Facebook的身份驗證，用戶將登錄到該網站。直到他/她從網站註銷，而不管Facebook的登錄狀態如何，它都將繼續使用它。像大多數其他網站一樣。Facebook的客戶端身份驗證是否足夠安全？
在研究FB的客戶端登錄方法時，我注意到它基於從fbsr_ {app_id} cookie收到的signed_request數據。而且FB希望在10分鐘內交換一個有效的短期access_token來驗證身份驗證請求。 （這10分鐘似乎是FB盡力減少安全漏洞的最大努力。）
但是，在這10分鐘內，別人可以複製cookie並且沒有太大困難，可以成功嘗試登錄爲受害者。這是我的關心和想請教以下問題：
我失去了一些東西在這裏關於FB的客戶端認證的安全性方面也確實這個弱點是什麼？
有沒有什麼我可以在我的執行中填補空白，或者正在轉移到FB的服務器端身份驗證唯一的答案？
是否使用服務器端流程或客戶端流程 - 如果使用正確，它們都是完全安全的。 正如你所提到的，在基於非SSL的網站上使用cookie選項確實是一個漏洞，但這是一個不受Facebook控制的漏洞。
如果你想完全避免這個攻擊媒介，不要使用cookie選項，而是使用你選擇的機制，例如通過SSL的XHR，將簽名請求從前端傳遞到後端。要做到這一點，只需訂閱相關事件 - 然後您的處理程序將與簽名請求一起作爲響應的一部分進行調用。
signed_request應始終在服務器上進行驗證以避免任何篡改或虛假使用。 signed_request還包含issued_at時間，它應該被驗證爲最近10分鐘內。 （對於FB的用戶標識，請使用隨其提供的user_id）。
擁有10分鐘的'代碼'生命並不是Facebook的弱點或控制器fb。但Facebook肯定可以通過客戶端登錄方式提高安全性。 – Ethan
您建議不要創建fbsr cookie，即始終使用cookie運行：false。如果沒有signed_request可用於其他後端處理程序（禁止登錄）來處理，則會立即產生影響，如增加服務器緩存條目的超時週期以刺激內存佔用空間或迫使用戶經歷頻繁的登錄過程，從而增加用戶的挫敗感並檢測處理程序在隨後的頁面訪問中添加ajax帖子，增加與後端的透明交互。這種方法的成本遠遠超過了解決登錄薄弱環節的收益。 – Ethan
@SeanKinsley您在處理signed_request方面的描述需要細化。我編輯了你的文章（最後一段）。 – Ethan
假設你使用的是HTTPS，你建議的是一個安全漏洞，這將是非常難以利用的。攻擊者基本上需要坐在用戶的機器上。但是，如果用戶沒有註銷，「攻擊者」總是可以這樣做。還是有另一種你認爲可以被利用的方式？ – Madbreaks
您正在查看OAUTH 2.0登錄工作流程，是嗎？ – Madbreaks
@Madbreaks是的，oauth2。並且目前不使用HTTPS。你真的不需要在受害者的機器上。在工作場所，你總是可以設法獲取cookie。我猜，10分鐘和一些方便的工具對我來說是個好時機。 （好吧，我不想在這裏擔心安全問題，但是試圖理解並選擇更好的選項來進行身份驗證）。 – Ethan