App> OAuth2服務器> Facebook> OAuth2服務器> App

Question

所以我有一個單頁客戶端應用程序。

正常流程：

應用程序 - >的OAuth2服務器 - >應用

我們有自己的OAuth2服務器，所以人們可以登錄到應用程序，並獲得與用戶實體相關聯的的access_token。 http://api.com/oauth2/auth?access_token=X&redirect_uri=http://app.com&response_type=token

我們的特別流動..

我們也有這種特殊的端點/的oauth2 /供應商/ Facebook的/ AUTH的client_id = Xredirect_uri = http://app.com

應用[1] - > OAuth2用戶服務器[2 ] - >實[3] - >的OAuth2服務器[4] - >應用[5]

[2]： 我們的URLEncode的REDIRECT_URI並將其傳遞作爲自定義參數給Facebook，所以我們可以重定向到http://app.com以後..

[3]：

我們的客戶重定向到Facebook的身份驗證和acccept應用。

[4]：

• Facebook的重定向到OAuth服務器，我們得到的 '代碼'。
• 我們要求一個access_token，我們得到access_token。這一切都發生在CURL的幕後。
• 我們用自定義授權類型（我們將其命名爲http://api.com/facebook，每個oauth2規範）向我們請求我們自己的API（對本地主機的內部API調用）。這是通過客戶端祕密完成的，並在CURL後面發生。
• 我們重定向到最初提供的原始redirect_uri。

這是一個適用於Facebook認證的方式嗎？

我們知道這可以用另一種方式完成，例如，瀏覽器首先要求獲得一個Facebook標記，然後瀏覽器要求一個access_token最終傳遞給我們自己的oauth2端點以進行進一步的驗證和處理，這對於客戶來說是兩個請求，對我而言這似乎相當緩慢和麻煩。或者是？

Answer 1

是的，這是一個可以接受的方式。這是所謂的「聯邦」的一個例子。

聯邦當然最好從它的實施WS-Federation知道。但是，您也可以使用OAuth來完成這項工作，即使這樣做的方式並不標準化。它已經完成，例如在The Identity Hub。

強硬只是幾句話：

在步驟4，您的訪問令牌和刷新令牌交換Facebook的代碼。然後，您需要再次撥打Facebook，以獲取用戶的個人資料（或至少他們的用戶ID）。你需要這個，以便當用戶回來後，​​你知道它是同一個用戶。 如果您打算稍後調用Facebook API（例如，檢查更新的配置文件），則需要將訪問令牌和刷新令牌存儲在與Facebook用戶標識關聯的授權服務器中。

換句話說，您需要有一些內部機制將Facebook用戶標識映射到您自己的內部用戶標識。如果您專門使用Facebook進行身份驗證，則Facebook用戶標識和您的內部用戶標識可以相同。您可以使用內部映射表，或者您可以使用例如Facebook用戶標識的前綴。 「臉譜」。這與WS-Federation稱之爲最初的發行者類似。

那你說

我們要求自己的API（內部API調用本地主機）與自定義交付式（我們將其命名爲http://api.com/facebook每次的oauth2規範），這個。這是通過客戶端祕密完成的，並在CURL後面發生。

這聽起來很奇怪。首先，您已經在授權服務器中。當然你可以調用一個內部函數而不必通過HTTP協議棧？這將會更有效率。此外，出於安全原因，請始終避免使用內部HTTP（S）端點。它們不僅不是必需的，還會增加攻擊面，並且需要花時間保護它們。