具有桌面应用程序安全性的 OAuth2 [英] OAuth2 with Desktop Application Security

问题描述

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

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

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

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.

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

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:人们只会访问他们自己的文件.就像他们在 drive.google.com 上一样(读/写/删除文件)

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

推荐答案

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

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.

至于一般的 OAuth 2.0 认证方式...

As for general OAuth 2.0 authentication methods...

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

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

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

1. 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

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

• 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.

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

• 同 1.

• 同 2.

这篇关于具有桌面应用程序安全性的 OAuth2的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！