使用redirect_uri的Facebook的客户端身份验证流程是否已损坏？

Question

如果我理解正确，要从我的桌面应用程序进行API调用（让我们从现在开始调用它，就像在OAuth2标准中那样调用'client'）我需要获取一个access_token，它是一个结合了应用程序ID和用户，我想访问的数据，id（'资源所有者'）。

遵循身份验证指南（developers.facebook.com/docs/authentication/）上的客户端流程我明白我需要向h ** ps发送请求：http：//www.facebook.com/dialog/oauth？client_id = YOUR_APP_ID＆amp; redirect_uri = http ：//example.com& RESPONSE_TYPE =令牌。结果，该页面将被重定向到h ** p：//example.com/#access_token=XXX。如果客户端是纯桌面应用程序，则redirect_uri可以是h ** p：//www.facebook.com/connect/login_success.html。由于客户端拥有Web控件，因此可以从重定向的地址轻松提取access_token。

客户端流程包含3个OAuth步骤：

1. 用户身份验证，如果资源所有者未登录Facebook，则会显示一个询问Facebook凭据的对话框。如果资源所有者已登录，则将使用Facebook服务器上的cookie对会话进行身份验证。安全 - 检查V！
2. 应用程序授权，如果资源所有者尚未授予应用程序权限，则权限对话框将要求资源所有者向应用程序授予权限，如果资源所有者先前已获得所有必需的权限，则权限对话框将不会显示。安全 - 检查V！
3. 应用程序身份验证 - 现在，这里是粘性的地方。该指南说：“通过验证redirect_uri与开发人员应用程序中配置的站点URL位于同一域中来处理应用程序身份验证”。安全 - 在我看来 - 失败！

为什么我认为最后一步是安全性失败？首先，app id和redirect_uri都是任何人都可以获得的公共信息。其次，redirect_uri可以是h ** p：//www.facebook.com/connect/login_success.html。

让我们看看以下场景。桌面应用程序EVE向用户显示一个Web控件，用户登录到Facebook并授予EVE一些基本权限。资源所有者没有理由怀疑任何事情。接下来，EVE隐藏了Web控件，并尝试在其上加载h ** ps：//www.facebook.com/dialog/oauth?client_id = OTHER_APP_ID ＆amp; redirect_uri = http：// www.facebook.com/connect/login_success.html&response_type=token。该应用程序可以尝试使用最受欢迎的Facebook应用程序ID加载此URL。如果用户先前已授权OTHER_APP，则应用程序将获得Success消息，因为将不会显示登录对话框和权限对话框。这将为EVE提供access_token，以访问资源所有者授予OTHER_APP而不是EVE的资源所有者的所有资源。

那么，这是一个安全漏洞吗？我错过了以下内容吗？

（UPDATE）

显然，对于桌面应用，安全问题无关紧要，因为应用已经拥有用户名和facebook会话甚至用户名和密码，它可以对用户帐户执行任何操作。

（UPDATE） 对于在Web浏览器中运行的JavaScript应用程序，redirect_uri实际上有效！ （见hnrt的回答和评论）。

当前问题： 唯一剩下的谜团是客户端身份验证如何在iPhone和Android应用程序上运行？安全整体是否与使用桌面应用程序时的整体相似？越狱的iPhone或扎根的机器人有什么不同吗？

干杯！

Answer 1

如果我理解正确，您的方案将要求用户已使用EVE可用于与Facebook通信的相同Web控件对其他应用进行身份验证。如果是这种情况，那么已经存在更大的安全问题:) EVE可能只是劫持整个会话及其所有身份验证令牌。

[更新]关于Javascript应用程序，same origin policy阻止EVE访问/dialog/oauth?client_id=OTHER_APP请求的回复。访问数据的唯一方法是在redirect_uri等待并解析重定向的请求。这里的“网站网址”保护工作开始了。

我不确定iPhone和Android应用程序的工作原理如何，但如果他们的Web控件允许访问其他应用程序的身份验证数据（= cookies），我会感到非常惊讶。