0

I stood up OAuth2-proxy as a reverse proxy in front of my application, following their instructions. The reverse proxy uses Google accounts for authentication, and uses an existing Google Group for authorization, per those same instructions.

Everything works for some lucky members of the group. Other cursed members of the group are refused access.

Logs reveal that the Google Admin API is responding that each of the lucky emails is in fact a member of the group, but each of the cursed emails is errantly reported as not a member of the group.

What is the difference between the lucky and the cursed? Examining https://console.cloud.google.com/iam-admin/groups/ for my organization and project shows a table with a curious Type icon.

Member table with curious type icon

All five of the group members with the icon are lucky: the Google API confirms they are members of the group. All four members without the icon are cursed.

The type icon is associated with the type google.apps.cloudidentity.groups.vx.membership.type.user. The five lucky members all have this type. The four cursed members do not. What is this type? It is mentioned nowhere in the public internet, until this SO question is posted.

Consider the two test emails freddiehubbard1971@yahoo and milesdavis1959@yahoo.com. Freddie and Miles were created at the same time. They are both Yahoo emails, with associated Google accounts. They are alike in every way, except somehow Freddie is lucky and Miles is cursed.

How did Freddie get tagged with google.apps.cloudidentity.groups.vx.membership.type.user and Miles did not? And more importantly how can I ensure that the non-test members of the group are so tagged?

David Bridgeland
  • 525
  • 1
  • 9
  • 16
  • 1
    That icon usually indicates that the email address does not belong to a Google account. I was able to reproduce the exact same behavior by adding to a group an email address of a user who does not have a Google account. Did the user `milesdavis1959@yahoo.com` by any chance create the Google account after or the same day of being added to the group? Have you tested by removing the user from the group and adding him again? – Fernando Lara Aug 23 '22 at 16:58
  • That's it! The icon indicates whether Google thinks the user has a Google account. Google apparently caches this information. If a user is added to the group before his Google account exists, the fact that there is no account is cached. If later the user created a Google account, the API will forever reply that he is not a member of the group. – David Bridgeland Aug 24 '22 at 10:05
  • It is good to hear it worked! If this answered your question, please click the accept button on the left (check icon). By doing so, other people in the community, who may have the same concern as you, will know that theirs can be resolved. If the accept button is unavailable to you, feel free to tell me. [How to accept answer](https://stackoverflow.com/help/accepted-answer) – Fernando Lara Aug 24 '22 at 17:59

2 Answers2

0

Fernando Lara provided the answer. Thank you.

An email address can be either be associated with a Google account or not associated. When an email is added to a Google Group, the group tracks whether the email is associated with a Google account. That tracking is shown as the icon, tagged with the type google.apps.cloudidentity.groups.vx.membership.type.user.

milesdavis1959@yahoo.com was originally not associated with a Google account. When asked about Miles, the group replies that Miles is not a member.

milesdavis1959@yahoo.com was later given a Google account. But the group does not update its tracking when Miles is given the account. When asked about Miles, the group continues to reply that Miles is not a member. Miles is forever cursed.

I claim this is a bug. Once Miles is associated with a Google account, the group should update its tracking of Miles, and confirm that he is a member. Or perhaps the group should confirm that Miles is a member, even before his email is associated with a Google account.

As Fernando points out, there is an easy workaround: remove Miles from the group, and re-add him.

David Bridgeland
  • 525
  • 1
  • 9
  • 16
0

Posting my answer from the comments for future references:

That icon usually indicates that the email address does not belong to a Google account. I was able to reproduce the exact same behavior by adding to a group an email address of a user who does not have a Google account.

The workaround for this is to just remove the email address from the group and add it again after making sure that the user has an active Google account with that email address.

Explanation:

This is not a bug or an issue, but an actual expected behavior due to how Google Groups and OAuth2 Proxy works, as it was mentioned in the post:

The reverse proxy uses Google accounts for authentication, and uses an existing Google Group for authorization, per those same instructions.

This means the app depends on an actual Google account to work correctly, and requires a GAIA ID which is only assigned to temporary and actual Google accounts.

Since the user before being added to the group did not have a Google account, and just adding an email address to a Google group does not create any temporary Google account (also called Nori accounts), then the OAuth2 Proxy app does not have any way to connect to this email address in the group.

Now, on the other hand, when the user created the Google account, then a GAIA ID was assigned to that email address, but the user was "stuck" in the group as a simple string of text that was part of the mailing list because it was added before creating the Google account, and the only way to change that would be adding the account again so the system can recognize the Google account, and associate the email address with the GAIA ID and that way the app will be able to recognize the user being part of the group and grant access.

Fernando Lara
  • 2,263
  • 2
  • 4
  • 14