OAuth installations without public endpoints for Socket Mode apps

[nickovs]

At the moment creating simple Bots in SocketMode is easy, but as soon as you want to support OAuth2 installation so that the bot can act on behalf of the user, a whole world of pain and complexity ensues.

The problem is that an app using Socket Mode only makes a single outbound connection, authenticated with its tokens, whereas to support OAuth2 it needs to expose an HTTPS endpoint with a valid certificate. These are very different beasts.

• A Socket Mode app can be run anywhere that can make an outbound connection. If you need OAuth2 then you need to expose the app to the internet.
• A Socket Mode app does not need to know its own DNS address. If you want OAuth2 you do.
• A Socket Mode app does not need a valid SSL certificate. To support OAuth2 you need one.

The requested enhancement, as proposed in this comment on another issue, is that Slack should offer a new API endpoint to provide an OAuth callback location for Socket Mode apps. The Slack API servers would present an endpoint with a URL of the form https://slack.com/api/oauth_redirect/MY_APP_ID and an app would use this in its OAuth2 installation process. When the user completes the OAuth2 flow this endpoint would be hit, the Slack servers would do some simple sanity checks on the values and then the tokens would be presented to the app as an event through the WebSocket connection. If the app is not connected at the time the API would reject the request, so the authentication process would not complete.

Offering this API would greatly simplify the process of deploying OAuth2 apps in Socket Mode. It would allow OAuth2 apps to run in Docker containers that don't have a good idea of where they are running or how they can be addressed. It would have the added security advantage of the app not having to expose any endpoint to the outside world.

Category

• slack_bolt.App and/or its core components
• slack_bolt.async_app.AsyncApp and/or its core components
• Adapters in slack_bolt.adapter
• Others

[seratch]

Hi @nickovs, thanks for writing in. Could you elaborate more on your question / feedback? If this is a question about how to enable OAuth callback endpoint while using Socket Mode for event handling, it's already feasible. This example app serves /slack/install and /slack/oauth_redirect endpoints for installation flow and connects to Slack for event delivery via a WebSocket conncetion.

If you have anything else to ask, let us know more details on it!

[nickovs]

@seratch Sorry, keyboard bounce caused me to submit too early! I hope the details above help.

[seratch]

Thank you for sharing the details. I see the benefits of your suggestion; however, I don't foresee our entire platform team investing in the enhancement to manage the OAuth callback endpoint on behalf of third-party app developers even in the long run (= years).

The only workaround I can suggest is to serve the OAuth flow through a different app, which can be safely exposed to the public internet separately from your Socket Mode event handling app. This means that both your OAuth app and Socket Mode app must share the same InstallationStore, storing the installation data in a database server that is accessible from both apps. I understand this might involve a somewhat complex architecture, but it's the only approach that meets your security requirements.

This might not be a fully satisfactory answer for you, but I hope it was somewhat helpful to you.

[nickovs]

I see the benefits of your suggestion; however, I don't foresee our entire platform team investing in the enhancement to manage the OAuth callback endpoint on behalf of third-party app developers...

@seratch Thanks for the reply. A couple of important things to note:

• Firstly, this would not require your entire platform team. It would require one new API endpoint to be created, and not a very complex one at that. Yes, this requires work by the backend team, but all the endpoint needs to do is confirm application ID and authorisation codes are valid and then insert the message into the existing message queue for events bound for the correct Socket Mode application. This is not rocket science.

• Secondly, the benefit here is not just for "third-party app developers". I'm a customer. My company spends more with Slack each year than many Slack engineers make as a salary. Lots of your customers build integrations; that's why you bother to have an API in the first place. You should be doing this for the benefit of the customers who keep the lights on at Slack.

Slack offers Socket Mode as a way to write apps. At the moment Socket Mode is incomplete; it can do nearly everything that can be done with web hook callbacks, but it fails to deliver one important security feature. By missing that feature its utility is severely limited.

Socket mode offers significant advantages to the customer:

• It is easier to deploy, since in most cases it can run anywhere that can host a single process and the host doesn't need to be routable from the internet or have a valid SSL certificate.
• It is easier to get approval in enterprise environments. Have ever you ever actually tried to deploy a web service that needs to be accessible to the public internet inside a major company that is subject to tight security rules?
• It offers better security, since there is only one source of input that will be processed by your app, instead of it being accessible to every attacker on the internet.

These reasons are precisely the sort of reasons that Slack offers Socket Mode, and then it hobbles the functionality by removing all of those benefits if you need to implement OAuth2 authorisation. A single new API endpoint to provide a generic authorisation grant callback would fix all of those, in one go, for all of your customers who use Socket Mode. Customers wouldn't even need to configure the endpoint URL when they install the app since (just like with several other Socket Mode settings) your servers would already have the answer.

So perhaps rather than dismissing the request as never happening, you could do all your paying customers a favour and file a feature ticket internally with the server team. You are welcome to connect them with me if they would like more detail.

[seratch]

Thank you for the detailed response.

Firstly, the term "third party app" I used in the previous comment was not suitable here. I meant any custom apps that are not built by Slack but understand it might not have been received that way. I should have said "custom app developers" instead.

Regarding the potential solution for this feature request, I don't think just adding a single API endpoint would work out. One possible approach could be sending the installation data, including tokens (meaning the oauth.v2.access API response data), through a WebSocket connection when a user installs the app via a kind of OAuth proxy on slack.com. This way, your app can store the per-user installation in your database. Currently, the platform does not offer such a mechanism, and more importantly, it may not fit the platform's security policies because this isn't a proven platform design with the OAuth protocol for multiple installers. However, I personally think this could be potentially an enhancement idea.

This issue tracker is dedicated to the client-side Python SDK. As maintainers of the SDKs, we're not in a position to make larger platform enhancement decisions beyond changes to the SDKs. Our company values customers' needs, so could you please send your feedback to our customer support team using your corporate Slack account? With this way, we can track the list of customers who need an enhancement. You can contact them via the /feedback command in your corporate Slack workspace or at https://my.slack.com/help/requests/new. Including the link to this issue URL would help our support agents understand the context. Also, please feel free to include more details or anything else specific to your company. We're sorry for this extra effort, and we'd appreciate your understanding.

I'll keep this issue open with the discussion label to receive feedback and comments from others on this topic.