JS客户端加密与OAuth：如何基于谷歌、脸书、推特令牌派生加密密钥

针对你这种服务端无需获取用户敏感数据明文、采用三家主流平台OAuth认证的开源SaaS场景，核心原则是所有密钥派生流程必须在用户客户端完成，绝对不能让服务端接触到派生密钥的原始输入，否则就完全失去设计意义。

核心设计红线：所有密钥原材料的读取、KDF计算、密钥存储全流程在用户端本地完成，服务端仅接收用户加密后的密文数据，全程不参与密钥派生逻辑。

通用派生流程（全平台兼容谷歌/脸书/推特） #

• OAuth授权完成后，客户端从回调链路直接拿到对应平台返回的令牌值，禁止将原始令牌上传到你的SaaS服务端做计算，从根源上杜绝服务端可以推导密钥的可能。
• 从OAuth返回的用户信息中提取三家共有的稳定身份标识：对应平台下的固定数字用户ID（谷歌的sub字段、脸书的user_id、推特的数字用户ID），不要选择用户昵称、显示名这类可修改的动态字段当派生输入。
• 采用标准化密钥派生函数（KDF）生成加密密钥，不要直接拿原始令牌当加密密钥：
  • 优先选HKDF-SHA256算法，完全满足非高敏级别的数据加密强度要求
  • 派生输入组合：原始OAuth令牌值 + 对应用户的平台固定ID + 应用全局固定Salt（直接写在开源客户端代码中即可，无需保密）
  • 派生输出长度匹配实际加密算法要求，比如用AES-256加密就取32字节长度的派生结果当密钥
• 生成的密钥直接存在用户端本地存储（浏览器IndexedDB、移动端系统级密钥库），后续所有标记为“服务端无需知晓”的用户数据，全在本地完成加解密，服务端仅存储最终的密文内容。

三家平台的针对性适配注意点 #

• 谷歌：优先用id_token而非短期access_token当派生输入。谷歌的普通access_token默认24小时过期，重新登录换发的令牌值不固定，会导致每次派生的密钥不一致、之前加密的数据无法解密；而id_token是代表用户身份的长期JWT，只要用户不撤销应用授权，重新登录拿到的id_token核心字段值稳定，不会出现密钥漂移。
• 脸书：直接申请长期权限的access_token当派生输入即可——脸书的长期令牌只要用户不主动撤销授权，值就固定不变，搭配应用固定App ID作为Salt的一部分，可保证密钥长期稳定。注意不要用2小时有效期的短期临时令牌，令牌过期换发后会导致密钥不匹配。
• 推特：用OAuth 2.0 PKCE流程下的长期access_token当派生输入，搭配推特侧的数字用户ID作为输入字段。推特的可修改昵称、用户名是动态值，绝对不能当派生输入的一部分，否则用户修改昵称后密钥就会变化，直接导致历史数据解密失败。

常见踩坑规避 #

• 不要在服务端执行密钥派生计算：只要原始令牌上传到服务端，服务端就具备了推导所有用户密钥、解密所有用户数据的能力，完全违背最初的设计目标。因为你的应用是开源的，把派生逻辑放在客户端代码里，用户可以自行审计代码有没有偷偷上传敏感字段。
• 不要用无Salt的简单哈希当密钥：比如直接对令牌做sha256哈希当密钥，这种生成方式抗彩虹表攻击能力极弱，必须加应用级的固定Salt，把你的应用派生的密钥和其他使用同OAuth令牌的应用隔离开。
• 提前处理令牌撤销的异常场景：如果用户在对应OAuth平台主动撤销了对你应用的授权，下次重新授权会拿到全新的令牌，此时派生的密钥自然会变化。这属于正常逻辑，需要给用户明确提示“因授权重新验证，之前加密的本地数据无法解密”，不要偷偷在服务端留存旧令牌来回放派生。
• 绝对不要把派生生成的密钥同步到服务端：密钥仅存在用户本地即可，就算后续服务端被拖库，攻击者拿到的也全是无密钥的密文，无法解密任何用户数据。

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