OAuth2与桌面应用程序安全性(OAuth2 with Desktop Application Security)

OAuth2与桌面应用程序安全性(OAuth2 with Desktop Application Security)

我有一个基本上是Google Drive客户端的Electron应用程序。 我打算使用OAuth 2。

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

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

我有什么办法可以缓解这个问题，或者这不是问题吗？

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

I have an Electron application that's basically a Google Drive client. I am planning to use OAuth 2.

However, Google API requires me to register my application where a client_secret is generated. Since this is a desktop application, I have my client_secret stored in a server. The authentication URL is generated in the server and sent to the user.

I'm worried that people can pretend to be the app and do things on behalf of my client_secret. If someone with malicious intent creates an unauthorized app and sends requests to my server, they could theoretically do malicious things on my application's behalf.

Is there anything I can do to mitigate this problem or is this not an issue?

edit: People will only access their own files. Just like they would on drive.google.com (read/write/delete files)

最满意答案

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

至于一般OAuth 2.0认证方法......

如果我们通过这里的动议，我们可以分析每种授权方法，并看看风险。 https://developers.google.com/identity/protocols/OAuth2

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

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

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

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

我会更乐意在这个问题上得到纠正，但我没有看到任何阻止上述问题的事情：P

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

Edit: Verifying that a request came from your desktop application and not a clone of it to your server is not really possible unless you control the locations where it is installed, but for a user program you don't. You can place some meagre barriers, but you can't provide any guarantees. It looks like iOS/Android are moving on this front, I imagine the only viable implementation would be for the OS to send a verified credential on your behalf, that is OS level support, not application level support.

As for general OAuth 2.0 authentication methods...

If we go through the motions here, we can analyse each method of authorisation and take a look at the risk of this. https://developers.google.com/identity/protocols/OAuth2

https://developers.google.com/identity/protocols/OAuth2WebServer (I think you're in this camp, but there's no client_secret here) Only risk of DOS against your client credentials. The responses are only ever acknowledged and forwarded to the specified redirect Uri, so requests can be made on your behalf for tokens, but only your server will ever receive the tokens (assuming the user agent is decent), you should deal with the case where you receive unknown token responses.

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

Risk of User installing a malicious app. When you lose the client_id, client_secret and the redirectUri (you have no way to keep these private against debugging of the device), then anybody will be able to make apps on your behalf. This is an unfortunate problem for mobile apps. The only defence is the User consent screen for now, that is, hopefully the User notices by looking at the consent screen that they have been duped into installing a malicious app from the store instead of your legitimate app.

I'd love to see some more work on this front, perhaps the App Stores could hold some credentials on your behalf and then confirm that it is your app requesting, I imagine that would involve some hash checking etc.

I'd be even happier to be corrected on this one, but I see nothing preventing the above problem :P

https://developers.google.com/identity/protocols/OAuth2UserAgent Same as 1. https://developers.google.com/identity/protocols/OAuth2ForDevices Same as 2.