带localhost重定向的OAuth2客户端ID分发是否安全？

一、硬编码Client ID的风险明确 #

你担心的问题完全成立：硬编码Client ID后，攻击者确实可以复用你的ID制作恶意应用。因为localhost重定向无法像HTTPS域名那样做专属管控，PKCE也防不了这种场景——它仅能防止授权码被第三方截胡，却无法阻止攻击者完整复刻你的授权流程，用户看到授权页显示你的应用名称，很容易被骗授权，进而泄露令牌。

二、安全分发Client ID的可行方案 #

1. 后端代理中转OAuth流程 #

搭建自己的后端服务，让桌面应用通过后端完成OAuth交互：

• 桌面应用启动后，先请求你的后端获取授权会话标识
• 授权发起、授权码换令牌全由后端完成，桌面应用仅接收最终的用户令牌（或后端封装后的权限凭证）
• 核心优势：真实Client ID完全不暴露给客户端，攻击者拿不到ID就无法伪造；同时可在后端校验应用合法性（比如代码签名、版本验证）

2. 开启应用签名校验 #

与第三方OAuth服务商协商，启用客户端证书校验或应用签名验证机制：

• 给你的桌面应用做官方代码签名，第三方服务商在颁发令牌前，校验请求携带的签名/证书是否合法
• 即便攻击者拿到你的Client ID，也无法复刻合法的应用签名，第三方会直接拒绝其令牌请求

3. 限制localhost重定向的端口与路径 #

多数OAuth服务商支持给localhost重定向URL指定具体端口和路径，比如http://localhost:8765/auth/callback：

• 固定桌面应用使用专属端口，仅将该带端口的URL提交给第三方审核
• 攻击者若使用不同端口，授权码会被重定向到无效地址，无法获取令牌；此方法作为基础防护，需配合其他方案使用

三、无需用户创建Client ID的替代方案 #

如果上述分发方案无法落地，可采用以下思路绕开用户自行创建ID的步骤：

1. 后端完全托管授权流程 #

桌面应用不直接与第三方OAuth服务商交互，所有操作通过你的后端完成：

• 用户点击登录后，应用打开浏览器访问你的后端授权页面，后端用自身Client ID发起OAuth流程
• 用户授权完成后，后端拿到令牌，再将令牌（或封装后的接口权限）返回给桌面应用
• 全程用户无需接触Client ID相关操作，完全无感知

2. 使用设备授权流程（Device Authorization Grant） #

若第三方服务商支持设备授权流程，这是专为无浏览器/无法输入的设备设计的方案，桌面应用适配性良好：

• 应用向第三方请求设备码与用户验证URL，展示给用户（比如引导用户用手机打开URL输入验证码）
• 用户验证后，应用轮询第三方获取令牌，全程无需localhost重定向；Client ID可硬编码，但因授权是用户主动在自身设备完成，攻击者复用ID时，用户能通过验证页的应用信息识别风险（建议搭配应用签名强化安全性）

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