为什么我不能在iOS应用程序订阅源对话框中使用服务器端流oauth令牌？

Question

我正在开发一款既有桌面网站又有原生iOS应用程序的产品。我们在两种情况下都为我们的用户提供Facebook连接作为登录选项。

我的意图是通过安全的JSON API共享相同的Facebook令牌，以便在两种情况下使用：当用户登录网络时，令牌会存储到我们的后端，以便当移动客户端下次运行时，它可以下载令牌并使用它，反之亦然。 （*这个方法的详细推理我在问题的最后解释，并不是问题的必要条件。）

问题：当iOS客户端使用令牌预设feed dialog时，如果该令牌是由网络使用server-side flow生成的，则对话框webview会出现错误：

“{我的应用名称}发生错误。请稍后再试。”

这是可靠再现的：

1. 使用服务器端流生成新的访问令牌。确保您请求publish_actions权限，因为您将使用提要对话框。
2. 使用隐身浏览器窗口（获取空的Cookie jar），查看iOS Feed对话框将在其网页浏览中呈现的m.facebook.com页面：https://m.facebook.com/dialog/feed?access_token=SERVER_SIDE_FLOW_ACCESS_TOKEN&app_id=YOUR_APP_ID&redirect_uri=fbconnect%3A%2F%2Fsuccess&sdk=2&display=touch

除＃2之外，您可以完成使用Facebook SDK创建虚拟iOS应用程序的所有工作（我已经完成），正确实例化并呈现对话框。为了再现错误，直接访问m.facebook.com供稿网址会更容易。

如果令牌是由原生Facebook iOS SDK而非服务器端身份验证流程启动的身份验证流程生成的，则上述Feed网址可以正常工作，如预期的那样。

此外，任何令牌（移动或服务器生成）都可以完美地用于直接通过图形api发布Feed项目。问题实际上只是移动供稿对话框。

Facebook是否故意禁止服务器端生成的令牌在移动Feed对话框环境中运行？

这是m.facebook.com上的Feed对话框端点的错误吗？

或者，希望我做错了什么？

---

为什么我要分享令牌？

• 由于删除了offline_access权限，因此当用户处于活动状态时，每个客户端（Web与移动设备）都可以从另一个客户端刷新相同的令牌中受益。这将导致令牌过期的实例减少，因此用户必须从头开始重新进行身份验证的情况会更少。
• 同样，用户不会经常被要求批准其他权限，因为每个客户都可以从其他客户的权限扩充中受益。

Answer 1

您从服务器端auth获得的令牌与客户端上的令牌不同（我将iOS / Android视为客户端）。 服务器令牌是长期存在的（60天），而客户端令牌是短暂的（几个小时）。

服务器端流程增加了另一层安全性，您的服务器会对Facebook服务器进行身份验证，这可能是您在使用此流时自动获得长期令牌的原因。

如果您使用访问令牌尝试debugger，您将收到有关令牌的信息，例如令牌的“来源”。 例如，从客户端auth（使用js）生成的令牌具有“Origin：Web”。 这意味着facebook确实可以区分令牌。

我不是百分之百确定这一点，但是从你的说法看起来听起来像facebook将UI限制为使用客户端令牌而不是服务器端，这可能是因为对话框让用户做事情无需应用程序获取权限，因此如果您有60天的令牌，您的应用程序可以使用它代替用户，并代表他做出事情并获得他的许可。 我只是在这里猜测。

我建议你只在服务器端使用服务器令牌，让iOS客户端处理自己的令牌。 根据{{​​3}}指南，它指出：

  

iOS原生应用

     

API错误由FBRequestDelegate接口处理。当你   检测访问令牌无效或已过期，您的应用程序   将需要多任务到Facebook iOS应用程序。假设   用户没有取消您的应用程序，他们将立即   通过全新的有效访问，多任务回到您的iOS应用程序   令牌。

这意味着您不必担心令牌在客户端过期。