Comment by rahimnathwani
4 days ago
If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com
How would they check that?
4 days ago
If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com
How would they check that?
By looking the account up with Google's People API - https://developers.google.com/people
They would have to verify the account is active, AND the id hasn't changed
If I log in using Google oauth, you already know the Google account is active.
Yes, but that's an additional check, separate from the one you suggested would eliminate the issue:
> If I log in using Google oauth, you already know the Google account is active.
You know there is an active Google account but (for the public OAuth integration option) it can be any Google account from any workspace, or no workspace.
"A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." [1]
> Yes, but that's an additional check, separate from the one you suggested would eliminate the issue:
If you set up an internal OAuth integration option no separate check is necessary, it will actually restrict access to users of your workspace.
"An internal application will only allow access to users from your organization (@your-organization.com)." [1]
You can use the SAML integration option as well. [2]
[1] https://support.google.com/cloud/answer/6158849?hl=en#zippy=...
[2] https://support.google.com/a/answer/6357481
Right, this additional check should not be necessary in a typical OAuth or OIDC flow. This workaround is only necessary in this case because the API Google offers to services has a hole in it.
Either slack or some other third party provider could have a whitelist maintained by IT?
Just spitballing.
It is certainly an option to pre-provision accounts in your application (e.g. Slack) and then have any users authenticating from the SSO product compared against the list of authorized users. And for some products which sell licenses by seat, this is exactly what they do.
But for many products which are meant to be available to an entire organization, this is a big part of what SSO was supposed to solve in the first place: IT no longer has to provision (and de-provision) user accounts in every single application. Maintaining an allowlist in each application makes this pointless.