從沒有服務器的桌面客戶端獲取OAuth的正確方法

Question

我正在開發一個擴展，它必須與Facebook連接才能下載某些用戶數據。我對OAuth dance的細節稍微有點新，並且還沒有能夠以期望的安全級別實現它。在目前的設置（運行）中，我擔心惡人劫持我的應用程序的名稱並使用它來發布垃圾郵件。

我已經嘗試了許多不同的技術來在我的擴展中實現OAuth（特別是使用Facebook進行登錄）。當前設置使用Facebook's Manual Login flow。

1. 在沙箱選項卡中打開OAuth彈出窗口。
2. 設置REDIRECT_URL特殊，internal facebook page不需要配置重定向的URL，設置的auth_token參數返回一個AUTH_TOKEN，而不是臨時代碼。
3. 將javascript注入特殊重定向頁面，該頁面通過auth_token將消息發佈到擴展。

可正常工作。我可以通過彈出窗口獲得應用程序權限後檢索用戶auth_tokens。

我擔心安全問題，因爲擴展沒有一個服務器存儲密鑰，它也沒有一個有效的域限制redirect_urls和驗證授權請求的真實性。由於這種流程：黑客可以簡單地將源代碼下載到我的擴展程序中，竊取Facebook應用程序ID，爲我的應用程序生成彈出窗口，並獲取可以通過我的應用程序發佈的auth_tokens。

更令人擔心的，在擴展的official Google Chrome gudie to OAuth建議嵌入在擴展您的CONSUMER_SECRET。這似乎與直覺相反。

我有理由相信這可以從兩個方面來解決：

1. 創建我自己的服務器充當我的分機和Facebook之間的代理。我可以將redirect_url設置爲我的自定義域，將consumer_secret存儲在我的服務器上，並在客戶端和我自己的服務器之間定義一個窄API。
2. 限制授權重定向到我的Chrome擴展ID（有點像Facebook iOS SDK使用App Store捆綁包標識符）。不幸的是，我無法將我的Facebook應用與Chrome擴展程序ID相關聯。它說「無效的網址」。

我更喜歡第二種選擇，因爲運行服務器可能代價高昂，併爲擴展引入另一個故障點。用戶還必須處理持有其auth_tokens的「黑匣子」代碼，這很糟糕。

有趣的是，它看起來像Facebook使得特殊例外的MS-應用：//網址（Windows 8的應用程序）。爲什麼不使用chrome-extension：// urls？

所以我的問題： - 這是可能的嗎？我錯過了什麼嗎？其次：我對這種劫持攻擊有偏見嗎？這看起來相當溫和，但我寧願不讓黑客劫持我的應用程序的oauth對話框。

謝謝

Answer 1

你的直覺是正確的。根據Facebook的開發者文檔的：

Never include your App Secret in client-side or decompilable code.

這樣做的原因正是你說什麼，即使是在編譯，混淆字節碼，它用現代的方法來反向工程應用的祕密是相當瑣碎即使您使用的是https。

在這種情況下，最好的做法是有一個託管的API，將通過外部源被用來代理所有的登錄，並隱藏您的應用程序ID和應用程序的祕密在一個單獨的配置文件。