从没有服务器的桌面客户端到OAuth的正确方法

Question

我正在开发一个必须与Facebook连接才能下载一些用户数据的扩展程序。我对OAuth舞蹈的细节有点新鲜，并且无法以期望的安全级别实现这一点。在当前的设置（有效）中，我担心恶人劫持我的应用程序名称并使用它来发布垃圾邮件。

我尝试了许多不同的技术来实现扩展程序中的OAuth（特别是使用Facebook登录）。当前设置使用Facebook's Manual Login flow。

1. 在沙盒标签中打开OAuth弹出窗口。
2. 将redirect_url设置为特殊的internal facebook page，不需要配置重定向URL，将auth_token参数设置为返回auth_token，而不是临时代码。
3. 将javascript注入特殊重定向页面，该页面使用auth_token将消息发布到扩展程序。

这可以按预期工作。我可以通过弹出窗口授予我的应用程序权限后检索用户auth_tokens。

我担心安全问题，因为扩展程序没有服务器来存储密钥，也没有有效的域来限制redirect_urls并验证授权请求的真实性。由于这个流程：黑客可以简单地将源下载到我的扩展，窃取Facebook App ID，为我的应用从他们自己的网站生成弹出窗口，并获得可以代表发布的auth_tokens “我的申请。

更令人担忧的是，扩展程序中的official Google Chrome gudie to OAuth建议将您的consumer_secret嵌入到扩展程序中。这似乎违反直觉。

我有理由相信这可以通过两种方式解决：

1. 创建我自己的服务器，充当我的分机和Facebook之间的代理。我可以将redirect_url设置为我的自定义域，将consumer_secret存储在我的服务器上，并在客户端和我自己的服务器之间定义一个狭窄的API。
2. 将授权重定向限制为我的Chrome扩展程序ID（有点像Facebook iOS SDK如何使用App Store捆绑包标识符）。很遗憾，我无法将我的Facebook应用与Chrome扩展程序ID相关联。它说“URL无效。”

我更喜欢第二种选择，因为运行服务器可能代价高昂，并为扩展引入了另一个失败点。用户还必须处理持有auth_tokens的“黑匣子”代码，这很糟糕。

有趣的是，看起来Facebook对ms-app：// URL（Windows 8应用程序）提出了特殊例外。为什么不chrome-extension：// urls？

所以我的问题： - 这可能吗？我错过了什么吗？第二：我是否对这种类型的劫持攻击感到偏执？这似乎相当温和，但我宁愿不允许黑客劫持我的应用程序的oauth对话框。

谢谢

Answer 1

你的直觉是正确的。根据facebook的开发者文档：

  

Never include your App Secret in client-side or decompilable code.

这就是你说的原因，即使在编译的混淆字节代码中，即使你使用https，使用现代方法对app秘密进行逆向工程也是相当简单的。

这种情况下的最佳做法是拥有一个托管api，用于通过外部源代理所有登录，并在单独的配置文件中隐藏您的应用ID和应用秘密。