Hacker News Reader

Comment by nodamage | Hacker News Reader

I'm not talking about checking against the domain, but checking against a directory of active users.

Where does this “directory of active users” exist? If it is controlled by slack, then you are relying on a failed startup to properly notify ALL the 3rd parties when they shut down. Failed startups don’t always shut down cleanly like that.

> Failed startups don’t always shut down cleanly like that.

Agreed, and with the number of services and the "ease" of oauth it's likely impossible to even track. You could make a list of the major ones, but there could be hundreds per user, ultimately thousands of unique services used depending on the breadth of the startup's activities.

That's what an identity provider (e.g. AD, OneLogin, Okta, Duo SSO, Google OAuth, etc.) is supposed to be, ostensibly.

Yes. If you've set up your Slack so each login checks against the identity provider to ensure an active user is logging in, that would resolve the issue, no?

Even if you take over company.com's domain you can't reconfigure company.com's Slack to point to a new identity provider?

I think you may be a bit confused about the players here. When you use Google OAuth to login, it _is_ your identity provider, and it is reporting to Slack that the user exists. Google is reporting the user exists because it exists in the Google Workspace directory. You use this as your source of truth for provisioning users, and they automatically get access to all of your company's apps.

The problem is that even though the user has the same email (joe@example.com), and the same Google Workspace domain ("hd": example.com), this is actually a _new_ Google Workspace account. But nothing Google provides to Slack allows them to detect this.

Slack, et al can fix this by _not_ using the public Google OAuth integration, and forcing every use to configure an individual internal Google OAuth integration. But they use the public one because Google has said it is a safe and secure way to operate their service.

What I'm suggesting is if you were able to pre-configure Slack to only allow logins for valid users from Google Workspace X, then even if someone creates a new workspace Y with the same domain, Slack would still be checking against workspace X. (And similar for non-Google based identity providers.)

And people are telling you that this is not possible with the Google public OAuth API. When Slack asks Google's public OAuth instance if user abc@example.com is valid, Google checks with the Google Workspace associated to example.com, and returns to Slack a response saying "yes, that user is valid, here is more information from example.com". This can be the same Workspace or another one, Google isn't really telling Slack apparently.

Now, there is another field called "sub", that should be a unique ID for the Google Workspace or the specific account, but it seems that this is not always stable, per the article, so people integrating with Google OAuth don't trust it.

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

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

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.

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

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

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

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

Where would this directory be stored?

Reply on news.ycombinator.com