为什么Google Admin API需要这个晦涩的属性来确认某人是Google组的成员？

Question

我在我的应用程序面前站起OAuth2-代理作为反向代理，遵循他们的指示。反向代理使用Google帐户进行身份验证，并根据相同的说明使用现有的Google进行授权。

每件事都适合这个团体中的一些幸运的成员。该组织的其他被诅咒成员被拒绝进入。

日志显示，谷歌管理API ( Google Admin API)的回应是，每封幸运邮件实际上都是该小组的成员，但每封被诅咒的电子邮件都被错误地报道为不是该小组的成员。

幸运者和被诅咒者之间有什么区别？检查我的组织和项目的https://console.cloud.google.com/iam-admin/groups/显示了一个具有好奇的类型图标的表。

​

​

拥有该图标的所有五个组成员都是幸运的: Google确认他们是组的成员。所有四个没有图标的成员都被诅咒了。

类型图标与类型google.apps.cloudidentity.groups.vx.membership.type.user.相关联。五个幸运的成员都有这种类型。四个被诅咒的成员没有。这是什么类型的？在公共互联网上没有提到这一点，直到这个问题被发布。

考虑一下这两封测试邮件freddiehubbard1971@yahoo和milesdavis1959@yahoo.com.弗雷迪和迈尔斯是同时诞生的。它们都是雅虎的电子邮件，有相关的谷歌账户。他们在各个方面都很相似，除了弗雷迪幸运，迈尔斯被诅咒。

弗雷迪是如何被google.apps.cloudidentity.groups.vx.membership.type.user标记的，迈尔斯却没有？更重要的是，我如何确保小组中的非测试成员被如此标记？

Answer 1

把我从评论中得到的答案发出来供以后参考：

该图标通常表示电子邮件地址不属于谷歌帐户。我能够复制完全相同的行为，添加到一个组的电子邮件地址的用户谁没有谷歌帐户。

解决这一问题的方法是删除组中的电子邮件地址，并在确保用户有一个具有该电子邮件地址的活动Google帐户之后再添加该地址。

解释：

这不是一个bug或问题，而是一个实际的预期行为，因为谷歌组和OAuth2代理是如何工作的，正如文章中提到的那样：

反向代理使用Google帐户进行身份验证，并根据相同的说明使用现有的Google进行授权。

这意味着该应用程序依赖于一个实际的谷歌帐户才能正常工作，并且需要一个只分配给临时和实际Google帐户的GAIA ID。

由于用户在被添加到该组之前没有谷歌帐户，而向谷歌组添加电子邮件地址并不会创建任何临时的谷歌帐户(也称为OAuth2帐户)，所以该代理应用程序无法连接到该组中的电子邮件地址。

另一方面，当用户创建Google帐户时，一个GAIA ID被分配到该电子邮件地址，但是用户作为一个简单的文本字符串被“卡在”组中，这是邮件列表的一部分，因为它是在创建Google帐户之前添加的，而唯一改变的方法是重新添加帐户，以便系统能够识别Google帐户，并将电子邮件地址与GAIA ID关联起来，这样应用程序就能够识别用户并授予访问权限。

Answer 2

费尔南多·劳拉提供了答案。谢谢。

电子邮件地址可以是与谷歌帐户相关联的，也可以是不相关的。当电子邮件被添加到Google中时，该组跟踪邮件是否与Google帐户相关联。该跟踪显示为图标，标记为google.apps.cloudidentity.groups.vx.membership.type.user.类型。

milesdavis1959@yahoo.com最初与Google帐户没有关联。当被问及迈尔斯时，这个小组回答说迈尔斯不是成员。

后来，milesdavis1959@yahoo.com获得了一个谷歌账户。但是，当Miles得到这个帐户时，这个组并没有更新它的跟踪。当被问及迈尔斯时，该团体继续回答说迈尔斯不是成员。迈尔斯永远被诅咒。

我说这是个窃听器。一旦Miles与Google帐户相关联，这个组应该更新其对Miles的跟踪，并确认他是成员。或者，小组应该确认Miles是成员，甚至在他的电子邮件与Google帐户相关联之前。

正如费尔南多所指出的，有一个简单的解决办法:将迈尔斯从小组中移除，重新加入他。