有没有办法预先检查或避免 Google 的 Gmail / Google 日历 OAuth 审批流程中的范围复选框？

Posted 2023-03-25

【中文标题】有没有办法预先检查或避免 Google 的 Gmail / Google 日历 OAuth 审批流程中的范围复选框？

【英文标题】：Is there a way to pre-check or avoid the scopes checkbox in Google's Gmail / Google Calendar OAuth approval flow?

【发布时间】：2021-10-08 20:26:57

【问题描述】：

我们目前使用google-api-python-client 来处理面向用户的 OAuth 流程。我们有一些用户向我们发送电子邮件询问为什么他们的帐户没有成功导入，当我们查看时，他们的令牌没有适当的范围。例如，我们希望找到所有这些范围：

https://www.googleapis.com/auth/gmail.metadata openid https://www.googleapis.com/auth/userinfo.email

但我们只收到最后 2 个。当我们查看 OAuth 流程时，我们注意到我们的 OAuth 流程看起来像这样（应用名称和帐户名称已编辑）。请注意，请求范围有一个复选框，默认情况下该复选框未选中。 （从 2020 年年中到大约一周前，此流程有 2 个额外的确认步骤，但最后一个复选框默认选中。）

将其与流行应用 Fantastical 的 OAuth 流程进行比较（包括 Spark 在内的许多其他应用看起来相似）：

在 Google 的博客上找到链接到 this post 的 this *** answer 后，似乎有些应用程序被纳入第二个流程，但第一个流程是新的默认值。两个问题：

默认未选中的复选框似乎是一个相对较新的更改，我找不到任何有关它的文档。 这是新的默认行为，还是 OAuth 流程中的参数/某些东西我们可以更改为默认检查？ 如果未选中，用户会认为他们不需要检查它，所以他们按下继续，然后我们的应用程序必须抛出错误并向用户解释他们需要检查该范围复选框。现在复选框未选中似乎有点疯狂，因为它是一个范围我明确要求......这是这个流程的全部意义。

有什么方法可以使我们的流程与 Fantastical、Spark 和任何其他在 2018 年左右之前创建的 OAuth 应用程序仍然具有的旧的、更简单的流程保持一致？或者是否有其他旧应用程序过渡到新流程的 ETA？上面的谷歌博文称，新流程将“在 2019 年初扩展到现有客户”，所以我们在这个变化上逾期了大约 2.5 年。就目前而言，它使“新的” OAuth 应用程序（我们的应用程序是在 2019 年创建的，所以几乎不是新的......）处于一个令人难以置信的劣势，因为它有更多的步骤，需要明确的同意，更容易出现用户错误，并且看起来像我们的应用程序在任何方面都较少受到审查或“安全”，因为流程与用户受过培训为许多其他应用程序执行的操作非常不同。

这几个月来一直是个问题，因此也发布此帖子以帮助处于相同位置的任何其他人。如果它对任何人都有帮助，请提供一些额外的点：

如果我从那个神奇的流程中获取 client_id 和 redirect_url 并在我们的应用程序的链接中使用它，流程看起来与他们的流程相同。所以它似乎是由客户端 ID 驱动的，而不是 URL 或我们流程中发生的事情。

我们的应用已通过 Google 的第三方安全评估并通过，因此它可能与我们请求的范围或我们的应用在审批过程中的状态无关

我们的流程和 Fantastical 都发生在 webviews 中，所以它不太可能与原生与 webview 相关

这发生在我们请求的几个不同的范围内，因此它不太可能与我们要求的范围相关（例如，Fantastical 的范围比我们流程中的 gmail.metadata 范围更广泛/更严格地审查）

【参考方案1】：

在我的情况下（android 应用），禁用的复选框仅在请求范围和登录选项时出现。

我通过先进行简单登录并随后使用GoogleSignIn.requestPermissions() 请求其他范围来避免它。

除了不显示复选框之外，这种方法还有另一个优点：

正如Google's article 末尾所指出的，“profile”、“email”和“openid”不需要单独请求（登录时允许使用）。因此，在您登录后，您只需要为您的其他范围请求权限。这样，向用户显示的对话框就不会那么“吓人”了，因为它不包含灰显的权限。

归功于Max，他在对此answer 的评论中指出了这种方法。