如何保障外部网站嵌入UI组件对受保护API的调用安全？

现有方案的核心问题 #

• 前端存储API Key：不管是静态页面还是React服务端渲染环境，前端代码中的密钥都能被轻易提取，完全无安全性可言，恶意用户拿到后可随意调用你的API。
• 依赖CORS/Referrer校验：仅在浏览器环境有效，且Referrer可被篡改、CORS配置可通过代理绕过，只能作为辅助校验手段，不能作为核心安全机制。
• Auth0 OAuth方案：client_secret绝对不能放在前端，若仅用client_id则无法完成安全的OAuth流程（隐式授权本身存在令牌暴露风险）；同时你提到的无法区分多客户端的问题，也会导致无法针对不同订阅者做权限隔离和用量管控。

可行方案（无需订阅者修改后端） #

1. 域名绑定的临时令牌机制 #

• 流程：
  1. 订阅者在你的系统后台配置自身网站域名，生成绑定该域名的专属JWT令牌（令牌内包含允许的域名列表、过期时间、订阅者ID等信息）。
  2. 订阅者将令牌与聊天组件嵌入代码一同部署到自己的网站。
  3. 聊天组件发起API请求时携带该令牌，你的API服务先校验令牌签名、过期时间，再验证请求的Origin/Referrer是否在令牌允许的域名范围内。
• 优势：令牌与域名绑定，即使泄露也仅能在指定域名下使用；无需订阅者改动后端；访客无需注册即可使用。
• 注意：令牌需设置合理过期时间，允许订阅者在后台刷新；API层的Origin/Referrer校验需严格执行，避免被绕过。

2. 专属代理服务+域名白名单 #

• 流程：
  1. 你提供一个专属的API代理域名（如widget.yourdomain.com）。
  2. 订阅者嵌入的聊天组件所有请求均发往该代理地址。
  3. 代理服务先验证请求的Origin/Referrer是否属于已授权的订阅者域名（你后台维护订阅者域名白名单），验证通过后，再使用内部API密钥转发请求至实际API服务。
• 优势：订阅者前端无需存储任何敏感密钥，所有密钥都在你的代理服务内；无需订阅者修改后端；访客无额外操作成本。
• 注意：需为代理服务配置限流、防攻击策略，避免被恶意请求拖垮；Origin/Referrer校验作为第一道关卡，配合后台白名单实现精准管控。

3. 挑战响应式无密钥验证 #

• 流程：
  1. 聊天组件初始化时，向你的API请求一个随机挑战字符串。
  2. 组件将挑战字符串与当前域名拼接，用你后台为该订阅者域名配置的专属哈希密钥（不对外暴露）进行HMAC哈希运算，生成响应值。
  3. 组件携带挑战字符串、响应值、当前域名发起请求，你的API用后台存储的对应域名哈希密钥重新计算哈希，与组件提交的响应值比对，同时校验域名匹配性。
• 优势：订阅者前端无需存储任何敏感信息，哈希密钥仅在你后台留存；即使挑战字符串被拦截，无密钥也无法生成有效响应，避免重放攻击。
• 注意：必须使用HMAC这类带密钥的哈希算法；挑战字符串需随机且单次有效。

结论 #

完全不开放API、不要求订阅者修改后端的前提下，是可以实现安全通信的。上述方案中，专属代理服务+域名白名单的实现成本相对较低，安全性有保障，同时便于后续做流量控制和日志统计。

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