要使用google drive api,我必须使用OAuth2.0进行身份验证.我对此有一些疑问.
客户端ID和客户端密钥用于标识我的应用程序是什么.但是如果它是客户端应用程序,它们必须是硬编码的.因此,每个人都可以反编译我的应用程序并从源代码中提取它们.这是否意味着一个糟糕的应用程序可以通过使用好的应用程序的客户端ID和秘密伪装成一个好的应用程序？所以用户会显示一个屏幕,要求授予一个好应用程序的权限,即使它实际上是由一个糟糕的应用程序询问？如果是,我该怎么办？或者实际上我不应该担心这个？
在移动应用程序中,我们可以将webview嵌入到我们的应用程序中.并且很容易在webview中提取密码字段,因为请求许可的应用程序实际上是"浏览器".那么,移动应用程序中的OAuth没有客户端应用程序无法访问服务提供商的用户凭据的好处？
这个问题是关于尝试了解在Android等移动平台上实现oauth所涉及的安全风险.这里假设我们有一个Android应用程序,其中包含嵌入在代码中的消费者密钥/秘密.
假设一个消费者的秘密受到了损害,并且黑客已经掌握了它,这会带来什么后果？
妥协的消费者秘密假设
我正确地指出,受损的消费者秘密对用户的安全性或用户正在与之交互的OAuth启用的提供商中存储的任何数据没有影响.数据本身不受损害,黑客无法检索.
黑客需要获得一个有效的用户访问令牌,这是很难得到的.
一个黑客可以用一个妥协的消费者秘密做什么？
我在说明以下内容时也是正确的:
最终用户的影响
在假设中
可能发生以下情况:
OAuth使用者(我的应用程序)影响:
我的应用程序(包含消费者秘密)需要更新,否则我的所有客户都无法授权我的应用程序代表他们做请求(因为我的消费者秘密将不再是有效的).
委派所有OAuth流量
尽管可以通过中间网络服务器委派大量OAuth交互(进行OAuth舞蹈并将访问令牌发送给用户),但也必须代理所有服务交互,作为消费者密钥签署每个请求需要/ secret.这是将消费者密钥/秘密保留在移动应用程序之外,并存储在中间网络服务器上更安全的地方的唯一方法吗？
替代
方案此代理有替代方案吗？是否可以将消费者秘密存储在中间网络服务器上,并且具有某种机制,即Android应用程序(在市场上发布并正确签名)可以向中间网络服务器发出安全请求以获取消费者秘密并存储它应用程序内部？可以实现一种机制,中间网络服务器"知道"这是一个请求获取消费者秘密的官方Android应用程序,并且中间网络服务器只会将消费者秘密分发给该特定的Android应用程序吗？
我有一个 Electron 应用程序，它基本上是一个 Google Drive 客户端。我打算使用 OAuth 2。
但是，Google API 要求我在生成 client_secret 的地方注册我的应用程序。由于这是一个桌面应用程序，我将 client_secret 存储在服务器中。身份验证 URL 在服务器中生成并发送给用户。
我担心人们可以冒充应用程序并代表我的 client_secret 做事。如果有恶意的人创建了一个未经授权的应用程序并向我的服务器发送请求，理论上他们可以代表我的应用程序做恶意的事情。
我能做些什么来缓解这个问题，或者这不是问题吗？
编辑：人们只能访问自己的文件。就像他们在 drive.google.com 上一样（读/写/删除文件）