Slack needs 2 providers

[tlpriest]

This change 9c692c2 moved slack from OAuth to OpenID, breaking existing integrations. While it is true that Slack now supports OpenID for authentication, it also still uses OAuth for authorization.

• OpenID for Slack - https://api.slack.com/authentication/sign-in-with-slack this is the new OpenID way to "Sign into a website" with Slack replacing their legacy OAuth flow.
• OAuth 2.0 for Slack - https://api.slack.com/authentication/oauth-v2 - this remains the method that app developers install slack apps into their workspace and get bot permissions like read channel list, post to channel, etc.

I think there needs to be 2 django-allauth slack integrations: one for Sign into this website with your slack account (OpenID), and another for install this application into your slack workspace (OAuth 2.0).

We're going to have to revert our version of django-allauth to the version prior to this change until we can rework things. But the move of the existing provider is likely going to break almost all existing django-allauth integrations using slack if they're doing anything other than simple login.

[pennersr]

I am wondering if the 2nd flow ("install this app into your slack workspace") makes sense in an allauth context, e.g.:

• When you add an app to the Slack workspace, it would also be presented as a way of signing in (in the 3rd-party provider accounts overview). That is actually an odd side effect, not?
• In order to get this flow going, allauth needs user information, and hence the identity scope, whereas your app may not even need that scope.
• If the user disconnects the 3rd-party provider account via the connections page, the app would still remain connected.

All in all, the above is a sign on the wall that things are being used for a purpose for which it was not intended. How do you deal with these issues?

[joonhyungshin]

I don't think allauth should handle the 2nd flow. The first flow is intended to allow users to login to a service using Slack credentials, for which allauth kicks in. On the other hand, the second one allows the service to act within a Slack workspace, and the user who initiates the flow (typically the admin of the workspace) is simply a delegate.

It is technically possible for allauth to handle the flow so that the entire workspace is registered as a Django user, but it is not a typical OAuth authentication and will overcomplicate stuffs to implement something that allauth is not indended to handle. I would suggest using the official Slack SDK for your use case.

[pennersr]

Closing for above mentioned reasons.