facebook-graph-api - 应用 > OAuth2 服务器 > Facebook > OAuth2 服务器 > 应用

Question

所以我有一个单页客户端应用程序。

正常流程:

应用程序 -> OAuth2 服务器 -> 应用程序

我们有自己的 OAuth2 服务器，因此人们可以登录应用程序并获取与用户实体关联的 access_token。 http://api.com/oauth2/auth?access_token=X&redirect_uri=http://app.com&response_type=token

我们的特殊流程..

我们还有这个特殊端点/oauth2/vendor/facebook/auth?client_id=Xredirect_uri= http://app.com

应用[1] -> OAuth2 服务器[2] -> Facebook[3] -> OAuth2 服务器[4] -> 应用[5]

[2]: 我们对 redirect_uri 进行 urlencode 并将其作为自定义参数传递给 facebook，因此我们可以重定向到 http://app.com稍后..

[3]:

我们将客户端重定向到 facebook 进行身份验证并接受应用程序。

[4]:

• Facebook 重定向到 oauth 服务器，我们得到了“代码”。
• 我们请求 access_token，我们得到了 access_token。这一切都发生在 CURL 的幕后。
• 我们使用自定义授权类型(我们根据 oauth2 规范将其命名为 http://api.com/facebook)请求我们自己的 API(对本地主机的内部 API 调用)，this.这是通过客户端 secret 完成的，并在幕后使用 CURL 进行。
• 我们重定向到最初提供的原始 redirect_uri。

这也是一种适用于 facebook 身份验证的方式吗？

我们知道这可以通过其他方式完成，例如浏览器首先请求一个 facebook token ，然后浏览器请求一个 access_token，它最终被传递到我们自己的 oauth2 端点以进行进一步验证和处理，这是对客户端的两个请求，这对我来说似乎相当缓慢和麻烦。或者是？

Answer 1

是的，这是一种可以接受的方式。这是所谓的“联邦”的一个例子。

Federation 最著名的当然是它在 WS-Federation 中的实现。 .但是您也可以使用 OAuth 来完成它，即使它的完成方式不是标准化的。以前已经做过，例如在The Identity Hub .

简单说几句:

在第 4 步中，您用 Facebook 代码交换访问 token 和刷新 token 。然后您需要另外调用 Facebook，以获取用户的个人资料(或至少是他们的用户 ID)。您将需要它，以便当用户稍后回来时，您知道它是同一个用户。 如果您计划稍后调用 Facebook API(例如检查更新的个人资料)，您需要将访问 token 和刷新 token 存储在您的授权服务器中，并与 Facebook 用户 ID 相关联。

换句话说，您需要有一些内部机制来将 Facebook 用户 ID 映射到您自己的内部用户 ID。如果您专门使用 Facebook 进行身份验证，则 Facebook 用户 ID 和您的内部用户 ID 可以相同。您可以使用内部映射表，或者您可以在 Facebook 用户 ID 前加上前缀，例如“Facebook:”。这类似于 WS-Federation 所说的原始发行者。

然后你说

We ask our own API (internal API call to localhost) with a custom grant type (we name it http://api.com/facebook per oauth2 specification), this. This is done with a client secret and is happening behind the scene with CURL.

这听起来很奇怪。首先，您已经在授权服务器中。您当然可以调用内部函数而不必通过 HTTP 堆栈吗？那会更有效率。此外，出于安全原因，请始终避免 secret 的内部 HTTP(S) 端点。它们不仅不是必需的，而且还会增加攻击面，您需要花时间保护它们。