改成 ux_mode: 'popup' 模式，通常并不能免除根据每个租户（不同二级域名）设置 JavaScript 来源白名单的要求。

在 Google 身份验证体系中，重定向模式和弹窗模式都属于 OAuth 2.0 流程，受到同样的安全限制。Google 要求开发者将授权请求发起的来源（Origin）添加到白名单中，这是为了防止跨域攻击和未授权的域名滥用。

针对你提到的“多租户二级域名”场景，目前主流的解决方案通常有以下几种：

• 方案一：配置泛域名（推荐尝试）
  在 Google Cloud 控制台的“授权 JavaScript 来源”中，检查是否支持配置通配符。如果支持，你可以填入 https://*.yourdomain.com，这样所有二级域名（如 tenant-a.yourdomain.com、tenant-b.yourdomain.com）都会被自动允许，无需逐个添加。

• 方案二：统一回调代理
  如果不支持泛域名，通常建议设置一个固定的、专门用于处理 OAuth 登录的独立域名（如 login.yourdomain.com）。

  1. 在白名单中只添加这个固定域名。
  2. 在多租户页面中，让弹窗或重定向跳转到这个固定域名进行授权。
  3. 授权成功后，再通过 postMessage 或 URL 参数将 token 传回对应的租户二级域名页面。这样后端只需要维护这一个白名单记录。

• 方案三：动态维护列表
  如果租户数量有限且相对固定，也可以在 Google Cloud 控制台中手动维护一个具体的二级域名列表。这种方式虽然管理成本稍高，但能确保安全性。

• 方案四：后端代理模式
  完全放弃前端直接调用，由你自己的后端服务器统一对接 Google API。前端只与你的后端通信，后端通过服务端凭证或固定的客户端凭证处理 Google 请求。这样前端不再直接调用 Google，也就绕过了 JavaScript 来源的白名单限制。

建议你优先检查 Google Cloud 控制台是否支持泛域名配置，如果不行，采用统一回调代理方案通常是多租户 SaaS 系统比较常见的处理方式。