我们有一个 SaaS 应用程序,可以读取用户的 Google 电子表格、文档并使用 OAuth2 凭据发送电子邮件。目前,我们为此应用程序维护两个经过验证的 OAuth 应用程序,两者均已批准用于相同的敏感和受限范围:
背景:
最初,我们创建了单独的 OAuth 应用程序,因为 Web 应用程序需要附加范围未包含在插件中。为了避免官僚主义和重新提交 App1 审批的风险,我们选择创建 App2。由于 Web 应用程序仍处于测试阶段,这种方法效果很好。
最近,这两款应用程序已获得相同范围的批准,因此可以将它们合并为一个应用程序,以简化维护和审批流程。我们决定使用 App1 来进行 Addon 和 Web App 授权。
应用程序以前如何工作:
这种方法多年来一直有效,没有出现任何问题。
最近的变化:
为了简化维护,我们合并了两个应用程序,现在使用 App1 进行所有授权(插件和 Web 应用程序)。由于 App1 和 App2 的范围相同,我们预计这种过渡是无缝的。
问题:
合并到单个应用程序(App1(现在存储的凭据仅适用于 App1,因为 App2 不再使用))后,一些域用户每天都会遇到凭据失效的情况。这是我们所知道的:
受影响的用户授权成功,没有任何警告,但他们的凭据将在 24 小时内被撤销。 该问题似乎仅发生在域用户身上,而不发生在我们自己或我们的测试域的用户身上。 它主要影响包含以下范围的凭证:
[
'https://www.googleapis.com/auth/gmail.addons.execute',
'https://www.googleapis.com/auth/script.container.ui',
'https://www.googleapis.com/auth/script.external_request'
]
通过 Web 应用程序撤销并重新授权凭据(无需通过插件进行预授权)可以解决该问题,但这是一个麻烦的解决方法。具有上述范围的域用户的凭据似乎将在 24 小时后过期。
注意: 并非所有域都会受到影响。例如,即使凭证中存在受影响的范围,我们的测试域也能正常工作。
有人知道可能是什么问题吗?
看起来您的代码中肯定存在需要更新的安全缺陷,或者数据库中的时间戳问题。但是,我确实认为您应该深入了解仪表板上的消息。