应用＆gt; OAuth2服务器＆gt; Facebook＆gt; OAuth2服务器＆gt;应用

Question

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

正常流程

App - ＆gt; OAuth2服务器 - ＆gt;应用

我们拥有自己的OAuth2服务器，因此人们可以登录该应用并获取与User实体关联的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

App [1] - ＆gt; OAuth2服务器[2] - ＆gt; Facebook [3] - ＆gt; OAuth2服务器[4] - ＆gt;应用[5]

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

[3]：

我们将客户端重定向到Facebook进行身份验证并接受app。

[4]：

• Facebook重定向到oauth服务器，我们得到'代码'。
• 我们要求access_token，我们得到access_token。这一切都发生在使用CURL的场景背后。
• 我们要求我们自己的API（对localhost的内部API调用）使用自定义授权类型（我们根据oauth2规范将其命名为http://api.com/facebook），这个。这是通过客户端秘密完成的，并且正在使用CURL在场景后面进行。
• 我们重定向到最初提供的原始redirect_uri。

这是一种适用于Facebook认证的方式吗？

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

Answer 1

是的，这是一种可接受的方式。这是所谓的＆＃34;联盟＆＃34;。

的一个例子

联盟当然以WS-Federation中的实施而闻名。但是你也可以用OAuth来做，即使它的完成方式没有标准化。之前已经完成过，例如The Identity Hub。

只有几句话很难：

在步骤4中，您将Facebook代码与访问令牌和刷新令牌进行交换。然后，您需要额外拨打Facebook，以获取用户的个人资料（或至少是他们的用户ID）。您需要这样，以便当用户稍后回来时，您知道它是同一个用户。 如果您打算稍后调用Facebook API（例如，检查更新的配置文件），则需要在授权服务器中存储访问令牌和刷新令牌，与Facebook用户ID相关联。

换句话说，您需要有一些内部机制将Facebook用户ID映射到您自己的内部用户ID。如果您专门使用Facebook进行身份验证，则Facebook用户ID和您的内部用户ID可以相同。您可以使用内部映射表，也可以将Facebook用户ID添加到例如前面。 ＆＃34; Facebook的：＆＃34 ;.这类似于WS-Federation称之为原始发行者的内容。

然后你说

  

我们要求我们自己的API（对localhost的内部API调用）使用自定义授权类型（我们根据oauth2规范将其命名为http://api.com/facebook），这个。这是通过客户端秘密完成的，并且正在使用CURL在场景后面进行。

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