最佳实践：GCP桌面应用OAuth客户端凭证应按用户还是按应用配置？

1. 按应用维度配置独立OAuth客户端凭证是否为最佳实践？ #

是，这是桌面应用接入GCP服务的官方推荐最佳实践，适配绝大多数场景，核心优势如下：

• 桌面应用属于公共客户端，本身无法安全存储客户端密钥，OAuth 2.0规范和GCP官方都要求公共客户端按应用维度统一使用一套客户端ID，不需要按用户拆分
• 该方案运维成本极低，只需要在GCP控制台管理1-2套凭证（测试、生产环境各一套即可），不需要额外开发凭证生成、存储、过期轮换的逻辑
• 单客户端ID的用户支持规模无硬性上限，只要你在GCP的OAuth同意屏幕页面完成应用发布验证，支持数十万甚至更高量级的用户使用完全没有问题
• 不会出现用户权限混淆的问题：每个用户通过该客户端ID完成OAuth授权后，你拿到的是该用户独有的访问令牌和刷新令牌，令牌本身已经实现了用户维度的权限、生命周期隔离，完全不需要拆分客户端ID做用户区分

注意：桌面应用的重定向URI请配置为http://127.0.0.1或者你自定义的应用专属回调scheme，不要把客户端密钥硬编码到桌面应用的安装包中。

2. 按用户维度配置独立OAuth客户端凭证是否为最佳实践？ #

不是，常规场景下完全不推荐该方案，仅在极少数有特殊要求的场景下（比如合规要求必须做用户级凭证隔离、需要给每个用户分配独立的GCP配额）才需要考虑，核心缺陷如下：

• 运维和开发成本极高：你需要为每个用户维护凭证的完整生命周期，包括创建、过期轮换、删除，同时还要保障凭证传输、本地存储的安全，出现凭证泄漏时溯源难度也极大
• GCP对单个项目下的OAuth客户端ID数量有默认配额限制（通常为100个/项目），即便申请提额也很难支持百万级以上的用户规模，适配性极差

如果确实有特殊需求必须按用户维度创建凭证，可以通过GCP的Cloud Identity API实现，核心流程如下：

• 在GCP控制台创建一个服务账号，授予该账号OAuth Client Admin角色，保证其拥有创建OAuth客户端凭证的权限
• 你的后端服务使用该服务账号的密钥调用对应接口，传入用户标识、应用类型、重定向URI等参数，为每个用户生成独立的客户端ID和密钥
• 生成的凭证通过加密通道下发到对应用户的桌面端，同时做好用户本地的凭证存储加密，避免泄漏

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