我已經倒在了OAuth2文檔和看到的的Facebook的Javascript SDK如何使用隱格蘭特安全問題。有關使用Facebook的隱含令牌服務器端資源服務器的OAuth2認證
我正在構建一個ReactJs應用程序，它與PHP-Symfony API進行通信。
我想要做的是在前端提供「使用Facebook登錄」選項。 我在我的PHP服務器上需要的是Facebook用戶ID和電子郵件以及用戶的其他數據，所以我最初可以在我的數據庫中爲他們創建一個用戶記錄，然後在返回訪問時使用身份驗證令牌再次獲取該信息服務器並使用它匹配到現有記錄和登錄的用戶。
我們這樣做之前使用的授權碼格蘭特方法前端重定向到我們的服務器，然後在Facebook，然後反饋給我們與身份驗證碼。然後，我們在服務器上使用我們的密鑰獲取訪問令牌，並將用戶信息從Facebook直接獲取到我們的服務器，然後對用戶進行身份驗證。
重定向對於單頁應用程序來說有點痛苦。 Facebook的Javascript SDK自動處理很多，但使用隱含授予，返回訪問令牌直接到前端。
我想知道的是，我可以將訪問令牌發送到我的服務器以執行與以前相同的身份驗證類型嗎？或者是我開放的一個巨大的安全漏洞？
兩相比較，該授權碼從授權碼格蘭特流也可通過前端去，但很快，不能直接把JavaScript和更短住。所以感覺更安全。 如果及時截取並且狀態匹配，它可以用來驗證我們服務器上的某個人，但不能直接訪問某人的Facebook數據。
從隱格蘭特流感覺它是開放給搞亂重用前端訪問令牌，但我不能把我的手指上的確切情況，將使其更容易受到攻擊。令牌可能會使人們不僅可以訪問我們的服務器上的身份驗證，還可以訪問人們的Facebook信息。
所以這最終是一個最佳實踐和安全問題。
我們認爲我們應該能夠實現我們自己的彈出式窗口，它會執行樣式流並檢索我們的服務器cookie，然後可以由產生它的頁面使用它，但它將會是棘手和大部分工作似乎是爲隱含授予方法，如果它是安全使用，因爲我們打算使用它。
謝謝。這真的很有用。尤其是這樣的部分：「任何使用授權過程作爲委託給客戶端的最終用戶身份驗證形式的規範（例如，第三方登錄服務）不得使用隱式流而沒有額外的安全機制客戶端確定訪問令牌是否爲其使用而頒發（例如，受衆限制訪問令牌）「。 – Jayd
根據此建議，我們決定在我們的應用中實施**授權代碼授權**。我們將嘗試彈出一個窗口來完成重定向流程，並獲取cookie或JWT，然後在父級上使用它來訪問我們的API。 – Jayd