API与合作方网站嵌入组件间安全共享认证令牌的方案探讨

方案1：直接信任合作方JWT令牌 #

• 适用场景：双方为深度战略合作伙伴，且合作方JWT的声明格式、签名算法、密钥管理完全符合我方安全要求
• 优势：前端流程极简，无需额外后端交互，用户无感知
• 风险：
  • 我方API需维护所有合作方的公钥/密钥集，密钥轮换时同步成本高
  • 无法控制令牌的有效期、权限范围，若合作方令牌泄露，我方API会直接受影响
  • 合作方JWT的用户身份信息（如邮箱）无法与我方用户体系关联，后续无法进行账号绑定、数据归属等操作
• 行业规范：仅适用于深度战略合作伙伴，且必须通过JWKS动态拉取公钥，禁止硬编码公钥；必须验证iss（签发方）、aud（受众）、exp（过期时间）等核心声明，同时严格限制令牌仅能调用组件所需的下单、信息收集接口

方案2：合作方后端换取我方JWT #

• 适用场景：绝大多数B2B合作场景，尤其是需要我方管控用户身份生命周期、权限范围的情况
• 优势：
  • 我方完全掌控令牌的生成、有效期、权限，可针对合作方用户设置专属角色（比如「合作方访客」），只允许调用组件相关API
  • 合作方用户信息（如邮箱）可与我方临时/正式账号关联，后续支持用户自主注册绑定
  • 后端交互避免前端暴露敏感凭证，安全可控
• 标准流程：
  1. 合作方后端用预先分配的API密钥/客户端凭证调用我方身份兑换接口，传入用户邮箱、合作方标识等信息
  2. 我方验证合作方凭证合法性后，生成包含sub（用户唯一标识，可格式为合作方标识:用户邮箱）、scope（组件所需权限）的JWT
  3. 合作方后端把这个JWT传给前端组件，组件用它调用我方API
• 行业规范：
  • 身份兑换接口必须用TLS加密，且仅允许合作方后端IP白名单访问
  • 生成的JWT有效期要短（比如15分钟），前端可通过合作方后端刷新令牌
  • 必须记录兑换日志，用于审计和异常排查

方案3：IdP发起的身份联邦（OAuth 2.0身份提供商联盟） #

• 适用场景：需要用户后续能直接访问我方系统，或对身份安全性要求极高（如金融、医疗场景）的情况
• 优势：
  • 完全符合OAuth 2.0/OpenID Connect规范，用户身份由双方IdP联合验证，安全性拉满
  • 用户完成一次联邦登录后，就能获得我方正式身份凭证，后续访问我方系统不用重复认证
  • 我方不用直接处理合作方用户信息，所有身份校验都由IdP完成
• 标准流程：
  1. 前端组件触发我方Auth0的登录流程，指定合作方IdP为身份提供者
  2. 用户被重定向到合作方IdP完成认证（如果已经登录就无感知）
  3. 合作方IdP把授权码返回给我方Auth0，Auth0验证后生成我方JWT令牌给前端组件
• 行业规范：
  • 必须使用OpenID Connect的IdP发起流程或服务提供商发起流程，别搞自定义流程
  • 我方Auth0需预先把合作方IdP配置为信任的身份提供者，验证其签名算法和公钥
  • 要处理用户首次登录时的账号关联逻辑（自动创建我方账号并绑定合作方身份）

最佳实践总结 #

• 优先选方案2作为通用方案：平衡了安全性、可控性和用户体验，适配绝大多数B2B合作场景
• 要是双方是深度战略伙伴，且不需要我方管控用户身份，可考虑方案1，但必须严格遵循JWT验证规范
• 若需要用户后续能直接使用我方服务，或对身份安全性要求极高，选方案3
• 不管选哪种方案，都得做到：
  • 所有API请求必须用TLS加密
  • 遵循最小权限原则，严格限制令牌的权限范围
  • 实现令牌过期和刷新机制
  • 保留完整的审计日志

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