[nodamage]

> And people are telling you that this is not possible with the Google public OAuth API.

Yes I understand, however it is possible to integrate Slack and Google SSO in such a way that it checks that the user belongs to the correct workspace, correct? Either via the SAML integration (https://support.google.com/a/answer/6357481) or an internal Google OAuth integration? The purpose of the public Google OAuth API as opposed to the previous two options is to allow logins from non-workspace or cross-workspace Google accounts, correct?

[SAI_Peregrinus]

No, there's no way to check which workspace is in use, just that the domain matches. That's the problem.

[nodamage]

Only if you use the Google public OAuth integration. If you instead use the SAML integration with Slack as described in the link above you don’t have this problem.

[radlad]

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. :)

[nodamage]

> 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.

[radlad]

>> 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.

[nodamage]

Your quote does not actually contradict my original statement, full reply here: https://news.ycombinator.com/item?id=42743263