有没有办法预先检查或避免 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?

问题描述

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

We currently use google-api-python-client to handle our user-facing OAuth flow. We had a few users email us asking why their accounts didn't import successfully, and when we looked, their tokens didn't have the appropriate scopes. For example, we expect to find ALL of these scopes:

https://www.googleapis.com/auth/gmail.metadataopenidhttps://www.googleapis.com/auth/userinfo.email

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

But we are only receiving the last 2. When we looked at the OAuth flow, we noticed that our OAuth flow looks like this (app name and account name redacted). Notice that there is a checkbox for the requested scope, and that checkbox is by default unchecked. (From mid 2020 to about a week ago, this flow had 2 additional confirmation steps, but that last checkbox was checked by default.)

将其与流行应用 Fantastical 的 OAuth 流程进行比较(许多其他应用，包括 Spark，看起来类似):

Compare that to the OAuth flow for popular app Fantastical (many others, including Spark, look similar):

在找到链接到 这篇文章在谷歌的博客上，似乎有些应用程序被继承到第二个流程中，但第一个流程是新的默认.两个问题:

After finding this StackOverflow answer which links to this post on Google's blog, it appears that some apps are grandfathered in to the second flow, but the first flow is the new default. Two questions:

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

1. The checkbox being unselected by default seems to be a relatively recent change, and I can't find any documentation about it. Is it the new default behavior, or is there a parameter / something in the OAuth flow we can change to have it checked by default? When it's unchecked, users assume they don't need to check it, so they press continue and then our app has to throw an error and explain to the user that they need to check that scope checkbox. It seems a bit crazy that now the checkbox is unchecked since it's a scope I'm explicitly asking for...it's the whole point of this flow.

有什么方法可以使我们的流程与 Fantastical、Spark 和任何其他在 2018 年左右之前创建的 OAuth 应用程序仍然具有的旧的、更简单的流程保持一致?或者是否有将其他祖父应用程序过渡到新流程的预计时间?上面的谷歌博文称，新的流程将在 2019 年初扩展到现有客户"，所以我们应该有大约 2.5 年的时间进行这项更改.就目前而言，它把新"放在首位.OAuth 应用程序(我们的应用程序是在 2019 年创建的，所以几乎不是新的...)处于一个令人难以置信的劣势，因为它的步骤更多，需要明确的同意，更容易出现用户错误，并且使我们的应用程序看起来像是在任何方面都较少受到审查或安全"因为流程与用户在许多其他应用中接受的培训大不相同.

Is there any way to make our flow consistent with that older, much easier flow that Fantastical, Spark, and any other OAuth application created before ~2018 or so still has? Or is there an ETA for those other grandfathered apps to be transitioned to the new flow? The above Google blogpost says the new flow will be "extended to existing clients at the beginning of 2019", so we're ~2.5 years overdue on that change. As it stands, it puts "new" OAuth apps (ours was created in 2019, so hardly new...) at an incredible disadvantage because it's more steps, requires explicit consent, is more prone to user error, and makes it look like our app is in any way less scrutinized or "secure" because the flow is so different from what users have been trained to do for many other apps.

这个问题已经存在好几个月了，所以也把这篇文章贴出来以帮助其他处于相同位置的人.一些额外的要点，以防它对任何人都有帮助:

It's been an issue for months now, so also putting this post up to help any others in the same position. Some additional points in case it's helpful for anyone:

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

• If I take the client_id and redirect_url from that Fantastical flow and use it in the link from our app, the flow looks the same as theirs. So it seems to be driven by the client ID, not the URL or something happening in our flow.

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

Our app has gone through Google's third party security assessment and passed, so it's likely not related to the scope we're requesting or our app's status in the approval process

我们的 flow 和 Fantastical 都发生在 webview 中，所以它不太可能与原生 vs. webview 相关

Both our flow and Fantastical's happen in webviews, so it's unlikely that it's related to one being native vs. webview

这发生在我们请求的几个不同的范围内，所以它不太可能与我们要求的范围相关(例如 Fantastical 的范围比 gmail.metadata 我们流程中的范围)

This happens with several different scopes we request, so it's unlikely that it's related to the scopes we're asking for (e.g. Fantastical's scopes are more expansive / scrutinized even more harshly than the gmail.metadata scope in our flow)

推荐答案

就我而言(Android 应用程序)，禁用复选框仅在请求范围和登录选项时出现.

In my case (Android app) the disabled checkboxes only appeared when requesting the scopes together with the sign-in options.

我通过先进行简单的登录然后使用 GoogleSignIn.requestPermissions() 请求其他范围来避免这种情况.

I avoided it by doing a simple sign-in first and requesting additional scopes afterwards with GoogleSignIn.requestPermissions().

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

Besides not showing the checkboxes, this approach has another advantage:

正如在 Google 文章的末尾所指出的那样、'profile'、'email' 和 'openid' 不需要单独请求(登录时允许).因此，在您登录后，您只需为您的其他范围请求权限.这样，向用户显示的对话框就不那么可怕"了，因为它不包含灰显的权限.

As pointed out at the end of Google's article, 'profile', 'email' and 'openid' don't need to be requested separately (they are allowed at sign-in). Therefore, after you sign-in, you only need to request permission for your additional scopes. This way, the dialog shown to the user is less 'scary', as it doesn't contain the grayed-out permissions.

感谢 Max，他在对此的评论中指出了这种方法答案.

Credit goes to Max, who pointed out this approach in a comment on this answer.

这篇关于有没有办法预先检查或避免 Google 的 Gmail/Google 日历 OAuth 批准流程中的范围复选框?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！