终结全局 Token：Ads / GSC / GA4 的 Per-Org OAuth
摘要
我们的多客户平台曾用一个存于 .env 的全局 OAuth token 读取 Ads/GSC/GA4 数据，存在跨客户泄漏风险，改配置还要重启。我们把它换成 per-org OAuth：token 按 org 存库、每次请求实时解析、缓存按 org 隔离、重授权自助化。
快速答案
别再共享一个全局 token。把 refresh token 按组织存进数据库，每次请求从 DB 实时解析当前组织的 token（不用重启），所有缓存键都带 org 维度，token 失效时让组织在设置页自助重授权。
在我们的多客户营销平台上，每个客户的 Google 数据——Ads、Search Console、GA4——曾经都通过一个存在 .env 文件里的全局 OAuth token 读取。能用，但一想到可能出错的地方就后背发凉：A 客户的广告数据被拉进 B 客户的看板。这就是我们彻底干掉那个全局 token 的故事。
我们一直忍受的风险
一个共享凭据带来两个问题。一是数据隔离：所有组织都走同一个 token，一次路由错配或映射错误，就能把某个客户的数据暴露给另一个客户——这是数据产品最糟的事故。二是运维：改凭据要改配置、重启服务，意味着一次本该无感的变更要计划停机。
方案：per-org OAuth
我们改成每个组织在自己的账号里独立授权 Google。Ads、GSC、GA4 三个渠道各自带独立的连接状态。refresh token 按组织存在数据库里，每次请求都从数据库实时解析当前组织的 token。没有共享凭据，改授权不用重启，.env 兜底被彻底移除。这个切换不是一把梭：每个组织的授权状态、token 生命周期、缓存命中，全部先在一个渠道上验证，再复制到其余渠道。
细节怎么守住安全
- token 失效走自助重授权。token 失败时，该组织去设置页重新连接，一个组织的重授权绝不碰别人的数据。
- 缓存按 org 隔离。所有缓存键都带 org 维度，任何缓存载荷都不可能跨租户泄漏。
- 定时任务按 org 解析。后台同步通过一个实时查库的 singleton 取当前组织的 token，而不是读全局配置。
重构分两个阶段推进——先 GSC 和 GA4，最后 Ads，每个渠道独立验证通过后再切换下一个。直到所有组织都通过新流程重新授权完成，.env 里的旧凭据才被删除。
可复用清单：多租户 OAuth 4 条
- 凭据按 org 存。token 放在数据库里，以 org 为键，绝不放共享文件。
- 请求时实时解析。每次请求都从数据库读当前组织的 token，变更即刻生效。
- 所有缓存都带 org 维度。缓存键必须包含 org，防止跨租户泄漏。
- 重授权自助化。token 失效就把用户引到重连流程，而不是来烦你。
如果你的平台还在用一份共享凭据读多租户数据，我们的营销分析平台刚做完的就是这次重构——per-org OAuth 是其中一部分。
常见问题
单个全局 token 有什么问题？
两个问题：数据隔离——所有组织共用同一凭据，一次路由错配就可能把 A 客户的数据泄漏给 B；运维——改凭据要改配置并重启服务。
为什么要每次请求都从数据库解析 token？
因为凭据会变。实时解析意味着重新授权或新组织立即生效，不需要重启，也没有需要失效的共享状态。
缓存怎么保证不跨租户泄漏？
所有缓存键都包含 org 维度，为一个组织缓存的数据永远不会被服务给另一个组织——哪怕命中的是同一条缓存。