欺骗facebook应用程序ID

跟进中概述的设计，特别是中列出的问题：缓解措施是什么

具体来说，我有一个web服务器，它公开了一个由移动应用程序使用的RESTAPI。我希望用户使用Facebook（通过应用程序）对服务器进行身份验证

现在，一个明显常见的流程是应用程序将用户重定向到Facebook，在那里他们将使用自己的凭据登录。然后，应用程序将获得一个令牌，并将其发送到服务器，服务器将使用graph API验证该令牌

但服务器如何确保令牌确实来自应用程序？具体来说，如何防止恶意应用程序供应商重新使用我的应用程序ID？毕竟，应用程序ID是硬编码到应用程序中的，因此可以被恶意应用程序提取和使用。如果用户使用Facebook登录到该恶意应用程序，则恶意供应商可以获得带有我的应用程序ID的令牌，并可以模拟我的服务用户

---

如何防止这种情况发生？

总结一下，对于那些碰巧想到这一点的人来说，确实没有办法防止客户端ID被欺骗。这是阻止开发人员在本机应用程序中使用OAuth隐式流的一个原因，Andre D在：

不允许在本机应用程序中使用隐式流 推荐的

（见附件）

---

实际上，如果有人发起此攻击，则用户将下载应用程序A（恶意应用程序），然后将被要求授权应用程序B代表其采取行动。据我所知，这通常是发生攻击的唯一迹象。

@CBroe感谢您的链接。我还没有看过这段视频（稍后会看），但从简短的阅读中我看不到我的问题的答案。事实上，他们说不应该假设

访问令牌来自使用它们的应用程序，而是应该使用调试端点检查它们，但是链接页面表明应用程序ID用于此验证。也许这意味着不应该将这些访问令牌发送到服务器？不，将它们发送到服务器是可以的。尤其是对于服务器端请求，您可以激活其他安全措施，例如要求提供应用程序机密证明。@CBroe您能否详细说明应用程序机密证明在这里有何帮助？据我所知，这是向Facebook证明服务器拥有应用程序机密的一种手段。但我的重点是向服务器证明用户通过了我的应用程序的身份验证。我同意你的观点，代币可以发送到服务器；我想我应该说，访问令牌不应该被发送到服务器以进行身份验证？“但我的重点是向服务器证明用户对我的应用程序进行了身份验证”—您将令牌发送到服务器，并对其进行调试。如果它不属于您的应用程序，此时您将看到。