时间戳

首页 > 解决方案 > 具有桌面应用程序安全性的 OAuth2

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

问题描述

我有一个电子应用程序，它基本上是一个 Google Drive 客户端。我打算使用 OAuth 2。

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

我担心人们可以假装是应用程序并代表我的 client_secret 做事。如果有恶意的人创建了未经授权的应用程序并向我的服务器发送请求，理论上他们可以代表我的应用程序做恶意的事情。

我能做些什么来缓解这个问题，或者这不是问题吗？

编辑：人们只会访问他们自己的文件。就像他们在 drive.google.com 上一样（读/写/删除文件）

标签： securityoauth-2.0google-drive-apielectrondesktop

解决方案

编辑： 验证请求是否来自您的桌面应用程序而不是将其克隆到您的服务器是不可能的，除非您控制它的安装位置，但对于您没有的用户程序。你可以设置一些微薄的障碍，但你不能提供任何保证。看起来 iOS/Android 正在朝着这方面发展，我想唯一可行的实现是操作系统代表您发送经过验证的凭据，即操作系统级别的支持，而不是应用程序级别的支持。

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

如果我们在这里走动，我们可以分析每种授权方式，看看这样做的风险。https://developers.google.com/identity/protocols/OAuth2

  1. https://developers.google.com/identity/protocols/OAuth2WebServer（我想你在这个阵营，但这里没有client_secret）
    • DOS 对您的客户端凭据的唯一风险。响应只会被确认并转发到指定的重定向 Uri，因此可以代表您请求令牌，但只有您的服务器会收到令牌（假设用户代理是体面的），您应该处理以下情况您收到未知的令牌响应。

  2. https://developers.google.com/identity/protocols/OAuth2InstalledApp

    • 用户安装恶意应用程序的风险。当您丢失client_id,client_secret和redirectUri（您无法将它们保密以防止设备调试），那么任何人都可以代表您制作应用程序。对于移动应用程序来说，这是一个不幸的问题。目前唯一的防御是用户同意屏幕，也就是说，希望用户通过查看同意屏幕注意到他们被骗从商店安装恶意应用程序而不是您的合法应用程序。

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

      我更乐意在这个问题上得到纠正，但我认为没有什么能阻止上述问题：P

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

推荐阅读