Comment by red_trumpet
Comment by red_trumpet 4 days ago
If the attacker is in control of company.com, checking against this domain would not help.
Comment by red_trumpet 4 days ago
If the attacker is in control of company.com, checking against this domain would not help.
> 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.
I'm not talking about checking against the domain, but checking against a directory of active users.