具有桌面应用程序安全性的OAuth2

时间:2018-07-18 10:05:00

标签: security oauth-2.0 google-drive-api electron desktop

我有一个Electron应用程序,它基本上是Google云端硬盘客户端。我打算使用OAuth 2。

但是,Google API要求我在生成client_secret的地方注册我的应用程序。由于这是一个桌面应用程序,因此我将client_secret存储在服务器中。认证URL在服务器中生成并发送给用户。

我担心人们会假装成为该应用程序并代表我的client_secret做事。如果有恶意的人创建了未经授权的应用程序并将请求发送到我的服务器,则理论上他们可以代表我的应用程序进行恶意操作。

我有什么办法可以缓解这个问题?还是这不是问题?

编辑:人们将只能访问自己的文件。就像在drive.google.com上一样(读取/写入/删除文件)

2 个答案:

答案 0 :(得分:4)

编辑: 实际上不可能验证来自桌面应用程序的请求,而不是将请求克隆到服务器上 ,除非您控制安装位置,但对于用户程序则不需要。您可以设置一些微薄的障碍,但不能提供任何保证。看来iOS / Android朝着这个方向发展,我想唯一可行的实现是OS代表您发送经过验证的凭据,即OS级别的支持,而不是应用程序级别的支持。

对于一般的OAuth 2.0身份验证方法...

如果我们在这里进行动议,我们可以分析每种授权方法并查看这样做的风险。 https://developers.google.com/identity/protocols/OAuth2

  1. https://developers.google.com/identity/protocols/OAuth2WebServer(我认为您在这个阵营中,但是这里没有client_secret
    • 只有DOS可能会对您的客户端凭据造成DOS风险。仅响应会被确认并转发到指定的重定向Uri,因此可以代表您发出令牌请求,但只有服务器会接收令牌(假设用户代理是不错的),那么您应该处理收到未知令牌响应的情况。
  2. https://developers.google.com/identity/protocols/OAuth2InstalledApp

    • 用户安装恶意应用的风险。当您丢失client_idclient_secretredirectUri时(您无法保留这些都是针对设备的调试专用),那么任何人都可以代表您制作应用。对于移动应用程序来说,这是一个不幸的问题。唯一的防御是现在的“用户同意”屏幕,即希望用户通过查看“同意”屏幕来通知,他们被欺骗是从商店而不是您的合法应用中安装了恶意应用。

      我很乐意看到这方面的更多工作,也许App Store可以代表您持有一些凭据,然后确认它是您的应用程序所请求的,我想这会涉及一些哈希检查等。

      我更愿意对此进行更正,但我看不出有什么可以防止上述问题的:P

  3. https://developers.google.com/identity/protocols/OAuth2UserAgent
    • 与1相同。
  4. https://developers.google.com/identity/protocols/OAuth2ForDevices
    • 与2相同。

答案 1 :(得分:-1)

我个人将创建一个代理服务,该代理服务模仿Google Drive REST API,但实现您自己的AAA机制。这样,所有机密信息都在服务器上得到了保护,您可以添加细粒度的访问控制。

相关问题