3 ms·

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

by nodamage 2y ago

batch12 2y ago
Where would this directory be stored?
radlad 2y ago
That's what an identity provider (e.g. AD, OneLogin, Okta, Duo SSO, Google OAuth, etc.) is supposed to be, ostensibly.
- nodamage 2y ago
  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?
  - radlad 2y ago
    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.
    - nodamage 2y ago
      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.)
      - tsimionescu 2y ago
        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.
        nodamage 2y ago
        > 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 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 2y ago
        No, there's no way to check which workspace is in use, just that the domain matches. That's the problem.
        2y ago
cortesoft 2y ago
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.
- chavesn 2y ago
  > 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.

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

batch12 2y ago

Where would this directory be stored?

radlad 2y ago

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

nodamage 2y ago
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?
- radlad 2y ago
  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.
  - nodamage 2y ago
    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.)
    - tsimionescu 2y ago
      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.
      - nodamage 2y ago
        > 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 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 2y ago
        No, there's no way to check which workspace is in use, just that the domain matches. That's the problem.
        2y ago

cortesoft 2y ago

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.

chavesn 2y ago
> 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.