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

Question

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

我尝试了许多不同的技术来在我的扩展中实现OAuth(特别是在Facebook上登录).当前设置使用Facebook的手动登录流程.

1. 在沙盒选项卡中打开OAuth弹出窗口.
2. 将redirect_url设置为不需要配置重定向URL的特殊内部Facebook页面,将auth_token参数设置为返回auth_token,而不是临时代码.
3. 将javascript注入特殊重定向页面,该页面使用auth_token将消息发布到扩展名.

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

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

更令人担忧的是,官方Google Chrome对扩展中的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 的开发文档：

切勿将您的应用程序密钥包含在客户端或可反编译代码中。

其原因正是您所说的，即使在编译的、模糊的字节代码中，使用现代方法对应用程序秘密进行逆向工程也是相当简单的，即使您使用的是 https。

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