针对 Google 商家资料，按安装分配的 OAuth 凭据不仅是一项安全最佳实践，更是 Google 服务条款的要求。那些在成千上万个站点间共享同一个客户端密钥的插件违反了规则，并让每个站点都面临风险。下面解释原因。
共享密钥错在哪里
一些老旧插件为所有客户硬编码同一个 OAuth 客户端 ID 和密钥。方便，便宜，却不安全。一次泄露就会暴露所有使用该插件的站点的凭据。
它还违反了 Google API 针对分发式应用的服务条款。
按安装分配是如何工作的
每个站点都创建自己的 Google Cloud 项目和 OAuth 客户端。凭据只存在于该站点上。GMB Poster 通过设置向导引导你完成，因此阻力极小。
如果某个站点被攻破，影响范围也只是一个站点。GMB Poster 插件让安全边界保持清晰。
安全地存储凭据
即便是按安装分配的凭据也需要加密存储。插件使用 AES-256-CBC 对客户端 ID 和密钥进行加密，密钥由你站点的 AUTH_KEY 常量派生而来。凭据在任何地方都不会以明文出现。
它们也从不出现在 REST API 响应或后台 AJAX 返回中。
轮换凭据
随时可以在 Google Cloud Console 中生成新的客户端密钥。把新值粘贴到插件里。加密存储随之更新。现有的刷新令牌会继续有效，或在下次使用时刷新。
每年轮换一次，或在有访问权限的员工离职时轮换。
合规与审计
对于受 GDPR、澳大利亚隐私法或美国州级法规约束的站点，按安装分配的 OAuth 会简化审计。凭据的范围限定在一家企业内。数据流向清晰明了。
审计人员更青睐这种更简单的模型。
常见问题
按安装分配的 OAuth 对 Google 商家资料来说更难设置吗？
只是略微。安装时一次性多花十分钟。在站点的整个生命周期内都免费。
如果我运营多个站点怎么办？
为每个站点重复一遍向导。或者如果你愿意，也可以用同一个 Google Cloud 项目配多个独立的客户端。
Google 要求生产环境必须按安装分配吗？
对于分发式插件来说是的。硬编码的共享密钥违反服务条款。
我可以把凭据分享给我的代理商吗？
设置阶段可以。凭据存放在站点上，而不是在代理商那里。
想在安全、合规的 OAuth 基础上搭建你的 Google 商家资料吗？Defyn 为澳大利亚企业设计并维护这类工作流程。
