← Back to context

Comment by johnmaguire

4 days ago

Bingo! Now looking back to your original comment, this is what I was trying to clarify:

> I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee.

It's a problem with Google's public OAuth implementation when used for private workspace accounts, despite Google's docs stating that this is a valid use. :)

3 comments

johnmaguire

Reply
nodamage  4 days ago

> despite Google's docs stating that this is a valid use. :)

I don't think Google's docs actually say this. I assume you are referring to the "hd" claim, but that only says:

"The domain associated with the Google Workspace or Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization. You must check this claim when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain."

It does not say you can use this claim to restrict access to members of a certain workspace, only for a certain domain.

I think certain service providers might have made the assumption that if a user belongs to a certain domain that also means they belong to a certain workspace, but that is clearly not a valid assumption.

I think that Google's public OAuth integration is only intended for use in situations where you want to allow logins from any Google account, regardless of workspace membership, and if you want to restrict logins to Google accounts belonging to a specific workspace, you are supposed to use one of the other integrations.

Given all that, I still do not think this is a problem with Google's OAuth implementation. Instead it is a problem with service providers who have incorrectly used the wrong type of Google SSO integration. Or in the case of service providers that offer multiple Google SSO integration options (like Slack), it is a problem with the company for selecting the wrong one.

  • johnmaguire  2 days ago

    >> I think certain service providers might have made the assumption that if a user belongs to a certain domain that also means they belong to a certain workspace, but that is clearly not a valid assumption.

    > If you need to validate that the ID token represents a Google Workspace or Cloud organization account, you can check the `hd` claim, which indicates the hosted domain of the user. This must be used when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain.

    https://developers.google.com/identity/gsi/web/guides/verify...

    FWIW, I worked on SSO products for nearly 5 years and am pretty familiar with this space.