关于使用 Facebook 隐式令牌进行服务器端资源服务器 OAuth2 身份验证的安全问题

Question

我翻阅了 OAuth2 文档并了解了 Facebook Javascript SDK 如何使用 Implicit Grant。

我正在构建一个 ReactJs 应用程序，它与 PHP-Symfony API 进行通信。

我想做的是在前端提供“使用 Facebook 登录”选项。 我在我的 PHP 服务器上需要的是 Facebook 用户 ID 和电子邮件以及用户的其他数据，因此我可以最初在我的数据库中为他们创建一个用户记录，然后在返回访问时，使用身份验证令牌再次获取该信息服务器并使用它来匹配现有记录并让用户登录。

我们之前已经使用授权码授予方法将前端重定向到我们的服务器，然后到 facebook，然后使用授权码返回给我们。然后我们在服务器上使用我们的 Secret Key 来获取 Access Token 并将用户信息直接从 Facebook 获取到我们的服务器，然后对用户进行身份验证。

重定向对于单页应用程序来说有点痛苦。 Facebook 的 Javascript SDK 会自动处理其中的大部分内容，但使用 Implicit Grant，将 Access Token 直接返回到前端。

我想知道的是，我可以将那个 Access Token 发送到我的服务器以进行与以前相同类型的身份验证吗？还是我要打开一个巨大的安全漏洞？

比较两者，Authorization Code Grant 流程中的 Auth Code 也通过前端，但速度非常快，不是直接到 JavaScript，而且寿命要短得多。所以感觉安全多了。 如果及时截获并具有匹配的状态，它可以用于在我们的服务器上对某人进行身份验证，但不能直接访问某人的 Facebook 数据。

重用 Implicit Grant 流程中的前端 Access Token 感觉好像很容易搞砸，但我无法确定具体的场景使其更容易受到攻击。该令牌可能使人们不仅可以在我们的服务器上进行身份验证，还可以访问人们的 Facebook 信息。

所以这最终是一个最佳实践和安全问题。

我们认为我们应该能够实现自己的弹出窗口，该窗口执行 授权代码授予 样式流程并检索我们的服务器 cookie，然后生成它的页面可以使用该 cookie，但它如果按照我们的意图使用它是安全的，那么大部分工作似乎都是针对 Implicit Grant 方法完成的。

Answer 1

最佳实践和根据RFC 6749

但是，应该权衡这种便利性和安全性 使用隐式授权的含义，例如在 第 10.3 和 10.16 节，尤其是当授权码 授权类型可用。