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

查看:133
本文介绍了具有桌面应用程序安全性的OAuth2的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个Electron应用程序,基本上是Google云端硬盘客户端。我打算使用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:People只会访问自己的文件。就像在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朝着这个方向发展,我想唯一可行的实现是OS代表您发送经过验证的凭据,即OS级别的支持,而不是应用程序级别的支持。

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可能会对您的客户端凭据造成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 /协议ols / 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.

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

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相同。

  • Same as 1.

  • 与2相同。

  • Same as 2.

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

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆