开发多客户端API时client id与secret应在注册还是登录阶段生成？

1. Client ID和Secret的生成时机 #

首先要区分业务场景判断生成逻辑：

• 如果是为官方自运营的多端产品（APP、小程序、网页端等）做身份校验，所有同类型官方客户端共用固定的client id + secret，提前由开发/运维在服务端配置好即可，不需要和终端用户的注册/登录行为绑定
• 如果是做开放平台给第三方开发者提供API接口，client id和secret应该在开发者完成平台入驻后，主动创建应用的时候生成，既不是普通用户注册阶段也不是登录阶段，一个开发者可创建多个应用对应多组凭证
• 如果业务需要给每个终端用户独立分配API调用凭证，就把生成入口放在用户个人中心的API申请模块，由用户主动触发生成，不要在注册/登录时默认生成，避免产生大量无用凭证浪费存储资源

2. 用户与Client ID的关联逻辑 #

• 官方客户端场景：不需要提前做绑定，只需要要求用户登录请求携带client id，服务端校验client id合法性后，在签发的用户登录态（如JWT、Session）中记录当前客户端标识即可，后续接口请求可直接从登录态提取client id，用于权限控制、数据隔离等逻辑
• 第三方开放平台场景：在用户给第三方应用授权的环节（如OAuth2授权码流程），将用户ID、第三方应用client id、授权权限范围三个字段关联，存储到独立的用户授权关系表中，后续第三方应用调用接口时，直接查表校验对应关联关系即可

3. Client ID和Secret的存储方案 #

服务端存储要求 #

• client id属于可公开的标识，直接明文存储在数据库即可，建议设置唯一索引提升查询效率
• client secret属于高敏感凭证，绝对不能明文存储，必须使用不可逆加盐哈希算法（如bcrypt、PBKDF2）处理后存储，校验时将客户端传入的secret用相同算法处理后和库中值比对即可，不要做解密操作
• 可额外为secret设置过期周期，定期提醒使用者更换凭证，降低泄露后的风险

客户端存储要求 #

• 网页端：禁止将client secret存储在前端代码、localStorage、cookie中，所有需要secret校验的请求必须走后端代理，前端仅可携带client id
• 原生客户端（APP、桌面端）：secret需做混淆加密后存储在本地，不要硬编码在代码包中，防止反编译泄露；如果是纯前端的第三方应用（如SPA单页应用），建议使用不需要secret的授权流程（如OAuth2 PKCE流程），从根源避免secret泄露问题

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