在过去的几个月里，我已经熟悉谷歌应用程序脚本中的OAuth2.0授权，但最近的一个异常让我感到困惑。我有一个独立的网络应用程序，充当融合表的前端。 web-app设置为“执行为”脚本和融合表所有者，融合表授予对外部用户的视图访问权限。程序检测授权，在需要时提示，并在可用时使用刷新令牌。从拥有脚本和融合表的帐户运行时，一切都很顺利。
我发布网络应用后，我从外部帐户进行了测试，效果很好。然后从脚本所有者的UserProperties中删除刷新令牌。当应用程序再次从外部帐户运行时，它会提示授权并正确授权（在脚本所有者的UserProperties中保存新令牌）。但是，对API的下一次POST调用收到403-Forbidden错误。此时，应用程序将继续从任何帐户（包括脚本所有者的帐户）收到403-Forbidden错误，直到手动清除令牌并重新授权为脚本所有者。
为什么这些令牌无效？我希望由于应用程序被“执行为”脚本/融合所有者，因此以编程方式接收的任何令牌都将与脚本/融合所有者授权的那些令牌一样有效。如果我的期望不正确，我怎样才能防止多个用户遇到这种情况？
我已经获得了更多的关注，并确定了一些我想在这里分享的相关问题。首先，我手动删除了令牌（刷新和访问）以测试应用程序授权的能力。后续授权未返回刷新令牌（这会导致过多的提示）。我发现这是谷歌API的故意结果。除了requisite request parameters返回刷新令牌之外，我发现刷新令牌仅在第一个用户提示和授权（ref. here）上返回。要获取另一个刷新令牌，您需要revoke-acess并在请求中重新授权或force the approval prompt。一旦我解决了这个问题变得更加清楚，令牌被“附加”给发出初始授权请求的用户。只要我保留了脚本/表所有者获取的刷新令牌，那么任何外部用户都可以使用该脚本（并使用刷新令牌以编程方式重新授权）。这让我回到了原点。如果我丢失了刷新令牌，我需要手动删除所有剩余的令牌报废，以脚本/表所有者身份登录，撤销对该应用的访问权限，然后重新授权。
Per Zig的答案如下，就是这样。我不能以编程方式阻止这种非常手动的过程吗？
答案 0 :(得分：1)
作为所有者执行的脚本将通过appscript内置身份验证自动保存所有者令牌。 但是，如果您自己进行oauth流程，它将保存用户的令牌，因此无法访问您的数据。