App > OAuth2服务器> Facebook > OAuth2服务器> App

Question

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

法线流：

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

我们有自己的OAuth2服务器，因此人们可以登录到应用程序并获得与用户实体相关联的access_token。type=token

我们的特殊流.

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

App1 -> OAuth2 server2 -> Facebook3 -> OAuth2 server4 -> App5

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

3.

我们将客户端重定向到facebook进行身份验证和访问应用程序。

4.

• Facebook重定向到oauth服务器，我们得到“代码”。
• 我们要求一个access_token，我们得到access_token。这一切都发生在幕后卷曲。
• 我们使用自定义授予类型(根据http://api.com/facebook规范命名为oauth2 )请求自己的API (对localhost的内部API调用)，这是这样的。这是一个客户的秘密，并发生在幕后卷曲。
• 我们重定向到最初提供的原始redirect_uri。

这也是一种使用facebook进行身份验证的实用方法吗？

我们知道这可以用另一种方式来完成，例如浏览器首先请求一个facebook令牌，然后浏览器请求一个最终传递到我们自己的oauth2端点进行进一步验证和处理的oauth2，这是对客户机的两个请求，对我来说，这似乎非常缓慢和繁琐。还是真的是这样？

Answer 1

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

当然，联邦最著名的是它在WS-联合会中的实现。但是你也可以用OAuth来完成它，即使它的方式是不标准化的。以前已经这样做过，例如在身份枢纽中。

我只想说几句严厉的话：

在步骤4中，将Facebook代码交换为访问令牌和刷新令牌。然后，您需要对Facebook进行额外的调用，以获得用户的配置文件(或者至少是他们的用户id)。您需要这样做，以便当用户稍后返回时，您知道它是同一个用户。如果计划稍后调用Facebook (例如，检查更新的配置文件)，则需要将访问令牌和刷新令牌存储在与Facebook用户id相关联的授权服务器中。

换句话说，您需要一些内部机制来将Facebook用户id映射到您自己的内部用户id。如果您只使用Facebook进行身份验证，那么Facebook用户id和内部用户id可以是相同的。您可以使用内部映射表，也可以在Facebook用户id前面加上例如"facebook:“。这与所称的原始发行者类似.

然后你说

我们使用自定义授予类型(根据http://api.com/facebook规范命名为oauth2 )请求自己的API (对localhost的内部API调用)，这是这样的。这是一个客户的秘密，并发生在幕后卷曲。

我觉得很奇怪。首先，您已经在授权服务器中了。当然，您可以调用内部函数而不必遍历HTTP堆栈？这样会更有效率。此外，出于安全考虑，始终要避免秘密的内部HTTP(S)端点。它们不仅是不需要的，而且还会增加攻击面，并且需要花时间保护它们。