node.js - 如何在 Electron 应用程序上正确存储 Google Drive API 的客户端 secret ？

Question

我有一个 Electron 应用程序需要访问用户 Google Drive，我想实现 api 功能而不必公开客户端密码。据我所知，这在某些情况下是不可能的，例如移动应用程序，但在本地应用程序上执行此操作的正确方法是什么？

尝试跟随 web-app 时来自 Google 的 OAuth 说明，看起来您不能在本地应用程序上使用此方法。当尝试以这种方式设置 OAuth 流程时，它甚至不允许您将 localhost 作为域列入白名单以对用户进行身份验证(这会破坏流程，因为这是在 Electron 上运行的本地应用程序)。再加上这个 paper谷歌发布了，你似乎也不能欺骗授权进程认为它没有在本地主机上运行，​​你也不能在浏览器中运行 Node.js(我使用的是 Electron，所以这是不可能的) .

然后我尝试关注他们的 Mobile and Desktop app看起来很有希望的工作流程。当您需要 Exchange authorization code for refresh and access tokens 时，问题就出现了.这再次要求您在主应用程序中显示您的客户端密码。然后我将其拆分并在本地执行其中的一些操作，然后拥有一个验证服务器来保存客户端 secret 并从客户端交换授权代码并返回刷新和访问 token 。看着 diagram Google 提供了可视化此过程的功能，它清楚地表明您的应用需要执行授权过程的两个部分，因此这个想法也被淘汰了。

我个人使用和查看的一个应用程序是 rclone，从外观上看，他们只是在他们的 code 中直接列出了他们的客户端 ID 和密码。 .客户端 secret 已加密，但如果您按照工作流程进行操作，它会通过同样为 stored locally on the app 的 key 显示出来。 .所以它的纯文本是模糊的，但是没有什么可以阻止任何人通过稍微修改代码来获取客户端 secret 。

我还应该提到这个应用程序在 GitHub 上的公共(public)存储库中，并将保持这种状态。

这是我第一次使用 OAuth，所以我可能误解了一些东西，但我尝试尽可能仔细地遵循文档并且无法摆脱我忽略了这个过程的一部分的感觉。

如果解决此问题的唯一方法是公开客户端 ID 和密码，这是否会导致用户数据泄露？由于 Google Drive API 是免费使用的，所以我并不介意其他人使用我的部分配额。我更担心安全问题。

Answer 1

对于您正在开发的桌面应用等公共(public)客户端，您需要使用 PKCE 流程。没错，Google 的文档似乎不在此处 - 您不需要将 client_secret 作为授权代码交换的一部分传递。

这里的文档支持:https://www.oauth.com/oauth2-servers/pkce/authorization-code-exchange/

Google 可能需要 client_secret，但它并未将该参数视为公共(public)客户的真正“ secret ”，而是一个不敏感的附加标识符，并且在其上不够充分拥有代表您的应用程序做任何事情。 Section 8.5 of the specification阅读:

Secrets that are statically included as part of an app distributed tomultiple users should not be treated as confidential secrets, as oneuser may inspect their copy and learn the shared secret. For thisreason, and those stated in Section 5.3.1 of [RFC6819], it is NOTRECOMMENDED for authorization servers to require client authentication of public native apps clients using a shared secret,as this serves little value beyond client identification which isalready provided by the "client_id" request parameter.

Authorization servers that still require a statically included sharedsecret for native app clients MUST treat the client as a publicclient (as defined by Section 2.1 of OAuth 2.0 [RFC6749]), and notaccept the secret as proof of the client's identity. Withoutadditional measures, such clients are subject to client impersonation(see Section 8.6).

您还可以查看独立的 OAuth 服务提供商，例如 Xkit我工作的地方。这样一来，您就可以在继续执行 OAuth 流程的同时对 secret 保密。