Electron应用对接Google Drive API时如何正确存储client secret

你完全可以在Electron应用中不内置、不暴露client secret完成Google Drive的授权接入，之前的所有试错都是因为选错了OAuth客户端类型、遗漏了公开客户端的标准安全扩展机制，根本不需要额外搭建授权服务器，也不需要走公开secret的兜底方案。

• Google 2020年之后的localhost可信域名限制，只针对Web应用类型的OAuth客户端。专门为本地程序设计的桌面应用（Desktop app）类型OAuth客户端，从来不受这套域名验证规则约束，原生支持本地回环地址、自定义深链接协议作为重定向URI，不需要绑定任何线上域名。
• 对于桌面、移动端这类无法在分发端安全存储机密的公开客户端，OAuth生态的标准解决方案是PKCE扩展，Google完全支持基于PKCE的无client secret令牌交换流程。你之前观察到的rclone内置secret的做法，是PKCE普及之前的历史遗留实现，现在已经完全不需要这么做。

1. 在Google Cloud Console创建OAuth凭证时，直接选择「Desktop app」类型，不要选Web application类型，这个类型的凭证不需要绑定任何线上域名，创建完成后你会拿到公开的client ID，配套的secret只是兼容旧流程用的，实际可以完全不用。
2. 全程走Authorization Code Flow + PKCE流程，不要用早年的JavaScript implicit flow：
   • 在Electron主进程中生成随机字符串作为code_verifier，计算它的SHA256哈希并做base64url编码，得到对应的code_challenge，指定code_challenge_method=S256。
   • 二选一确定重定向回调方式：
     • 临时回环端口：Electron主进程在127.0.0.1上随机开启一个临时HTTP服务端口，等拿到授权码后立刻关闭这个端口，这个临时地址可以直接配置为Desktop OAuth客户端的合法重定向URI，不需要Google做任何域名验证。
     • 自定义深链接协议：在操作系统层面注册一个你的应用专属协议（比如com.your-app-name://oauth-callback），将这个地址配置到OAuth客户端的重定向URI列表，用户授权完成后，Google会通过这个协议直接拉起你的Electron应用完成回调。
   • 调用系统默认浏览器（绝对不要用Electron内嵌的Webview加载授权页，Google会对嵌入式WebView内的OAuth请求做严格拦截，避免钓鱼攻击），跳转到Google授权端点，携带参数：公开的client_id、申请的Drive scope、你配置的redirect_uri、response_type=code、code_challenge、code_challenge_method=S256，全程不需要带任何secret。
   • 拿到重定向带回的授权码后，直接向Google令牌端点发POST请求，携带参数：code、公开的client_id、和之前一致的redirect_uri、code_verifier、grant_type=authorization_code，这个步骤完全不需要传client_secret，Google会校验code_verifier和之前提交的code_challenge是否匹配，匹配成功就会返回access token和refresh token，直接存在Electron的本地系统安全存储里即可。

如果你真的因为兼容等特殊情况，不得不把client ID和secret随应用代码公开，也不会带来用户数据泄露的隐患：

• Google从产品设计之初，就将Desktop、Mobile类型的OAuth client secret定义为非机密参数——只要是分发给普通用户的本地应用，无论对secret做多么复杂的加密、混淆、拆分存储，都可以通过逆向工程拿到明文，这是本地应用场景的固有属性，Google从未要求这类场景下对secret做严格保密。
• 公开这类secret的唯一影响是其他开发者可能复用你的client凭证发起钓鱼授权，消耗你的API调用配额，但完全没办法绕过用户的显式授权拿到任何用户的Drive私有数据。所有访问令牌都和用户的授权行为强绑定，没有用户主动同意的前提下，就算拿到完整的client凭证，也访问不到任何Drive资源。

你之前设想的“独立授权服务器持有secret完成令牌交换”的方案，其实是面向纯Web应用、多端共享登录态的场景设计的，对于桌面本地应用来说完全多余。PKCE机制已经在不引入任何额外服务器的前提下，解决了公开客户端的secret泄露风险问题，整个授权、令牌交换流程都可以在本地应用内完成，不需要依赖第三方服务。

内容的提问来源于stack exchange，提问作者stackiee