在过去的几个月里，我已经熟悉了谷歌应用脚本中的 OAuth2.0 授权，但最近的一个异常让我感到困惑。我有一个独立的网络应用程序，它充当融合表的前端。Web 应用程序设置为“执行为”脚本和融合表所有者，并且融合表授予外部用户查看访问权限。该程序检测授权，在需要时提示，并在可用时使用刷新令牌。从拥有脚本和融合表的帐户运行时，一切都很好。
发布网络应用程序后，我从外部帐户对其进行了测试，并且运行良好。然后从脚本所有者的 UserProperties 中删除了刷新令牌。当应用程序再次从外部帐户运行时，它会提示授权并正确授权（将新令牌保存在脚本所有者的 UserProperties 中）。但是，对 API 的下一次 POST 调用收到 403-Forbidden 错误。此时，应用程序将继续收到来自任何帐户（包括脚本所有者的帐户）的 403-Forbidden 错误，直到手动清除令牌并重新授权为脚本所有者。
为什么这些令牌无效？我希望由于该应用程序作为脚本/融合所有者“执行”，因此以编程方式接收的任何令牌都将与脚本/融合所有者授权的令牌一样有效。如果我的预期不正确，我该如何防止多个用户出现这种情况？
更新
我在这方面获得了更多关注，并确定了一些我想在这里分享的相关问题。首先，我手动删除了令牌（刷新和访问）以测试应用程序的授权能力。后续授权未返回刷新令牌（导致过度提示）。我发现这是谷歌 API 的故意结果。除了返回刷新令牌所需的请求参数之外，我发现刷新令牌仅在第一个用户提示和授权时返回（参考此处）。为了获得另一个刷新令牌，您需要撤销访问并重新授权或强制批准提示在请求中。一旦我解决了这个问题，令牌被“附加”到发出初始授权请求的用户就变得更加清楚了。只要我保留了脚本/表所有者获取的刷新令牌，那么任何外部用户都可以使用该脚本（并使用刷新令牌以编程方式重新授权）。这让我回到了重点。如果我丢失了刷新令牌，我需要手动删除所有剩余的令牌碎片，以脚本/表所有者身份登录，撤销对应用程序的访问权限，然后重新授权。
根据 Zig 在下面的回答，就是这样。我有没有办法以编程方式阻止这个非常手动的过程？