Facebook登录如何确保您的网络应用程序只能在您的URL中使用？

Question

当您使用Web应用程序与Facebook登录集成时，可以在Facebook上的应用程序设置中指定Web应用程序的URL。 尝试在未从该URL加载的页面上使用该应用程序的ID会产生相应的错误：“应用程序配置不允许给定URL。”

他们如何在不打败它的情况下做到这一点？ 如果该应用程序在http://example-a.com上获得授权，如果我复制应用程序ID并尝试从http://example-b.com使用该应用程序ID，它们如何阻止访问？ 我正在尝试理解他们是如何做到这一点的，因为我需要在我正在做的一些工作中执行类似的锁定原始URL。

我有一种强烈的错过这种明显的感觉。

我知道他们正在使用“ 基于 ” OAuth 2.0规范的授权/认证流程（并且基本流程并不完全复杂 ），但我无法确定他们验证的流程中的哪个阶段原始页面的URL以及他们如何将该URL发送到他们的服务，同时确保它没有被篡改/欺骗。

我（我想我已经）消除的事情：

1. 虽然我看到它们在原始域中传递（在查询字符串等中），但它们不能仅仅依赖于它，修改调用代码以“调整”它是微不足道的。 我希望这是解决方案的一部分 ，但只是其中的一部分。

2. 他们不能使用Referer （原文如此）标题，因为欺骗是微不足道的。

3. 它们不能使用（仅）在原始页面中运行的代码，因为可以修改它。

4. 他们不能只依赖于postMessage ，因为Facebook登录在IE8 / 9上工作，它是一个弹出窗口（不仅仅是一个框架）; IE8 / 9中的postMessage 仅适用于帧内 ，而不适用于单独的选项卡/窗口。

Answer 1

当我在问题中写下我的第四个要点时，我意识到他们可以做什么（并且检查了一些关于postMessage的非常有用的东西）。

我认为他们大致是这样做的：

• 加载到原始页面的Facebook代码（当然可以被黑客攻击 - 但稍后处理）会将从mumble.facebook.com加载的iframe添加到原始页面; iframe包含Login按钮。

• 原始页面上的Facebook代码使用postMessage与该iframe交谈。

• iframe代码 - 原始站点无法合理破解，因为它是从mumble.facebook.com加载的 - 使用它接收的事件对象的origin属性和来自原始页面的postMessage消息; 这就是它如何拥有原始起源的可靠版本。 这不能欺骗（除了浏览器错误）。

• iframe的Login按钮打开一个弹出窗口（从mumble.facebook.com加载），它使用opener （但不是postMessage ）与iframe对话（因为iframe和popup是从同一个源加载的，所以他们可以这样做 -因为IE8 / 9问题，他们必须而不是postMessage 。

• 然后是互动：

    + ------------------ + + -------- + + ------- +\n |  始发页面| < - > |  iframe | < - > |  弹出| <------ +\n + ------------------ + + -------- + + ------- + |\n                              ^ v\n                              |  + --------------------- +\n                              + ------------------> |  mumble.facebook.com |\n                                                  + --------------------- + 

基本上， iframe是原始页面和弹出窗口（以及一般的Facebook）之间的代理，并且在那个阶段（原始页面和iframe之间的通信）Facebook获得原始页面源的可靠版本。

我相信他们将原始来源作为查询参数传递给iframe作为附加度量; iframe可能会将它用于它发回到原始页面的任何消息，因此如果查询参数被黑客攻击，那些消息永远不会被原始页面接收，并且没有任何作用。 或者他们只是比较它们。

由于event.origin不能被欺骗（除了浏览器错误），而代码和标记等iframe和popup来自mumble.facebook.com ，它相当安全可靠（在网络浏览器领域“合理”） ）。

Answer 2

漂亮的Ascii图形:-)

我认为答案更简单，它适用于所有基于OAuth2的系统。 请求授权的应用程序发送一个redirect_uri参数，该参数必须与您在授权服务器（本例中为FB）中注册的内容相匹配。 如果您发送的内容与注册值不符，则会被拒绝。 我不相信他们检查推荐人或其他任何东西。 如果查询参数匹配，则授权服务器使用code将用户返回到redirect_uri （并且OAuth2流程继续：使用代码获取令牌等）。

应用程序还应发送在整个事务中保留的state参数，并在返回时进行检查。