Proper use of state parameter for the OAuth CSRF protection

[seratch]

Description

Refer to slackapi/node-slack-sdk#1435 for details but in the next minor version, we are going to change the internals of the OAuth flow in bolt-js. The improvement won't bring any breaking changes. Newer versions of bolt-js (v3.11 and newer ones) will handle the OAuth flow more properly under the hood.

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• example code related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

[pmezard]

Hello,

Not sure this is the right place to discuss it but I just upgraded from 3.10 to 3.11 and the OAuth flow stopped working with:

Error: The state parameter is not for this browser session.
   at new InvalidStateError2 (/node_modules/.pnpm/@slack/[email protected]/node_modules/@slack/oauth/src/errors.ts:28:1)
   at InstallProvider2.<anonymous> (/node_modules/.pnpm/@slack/[email protected]/node_modules/@slack/oauth/src/install-provider.ts:494:21)

Maybe I am not doing it right, I still have to investigate but The improvement won't bring any breaking changes might not be 100% correct.

[seratch]

@pmezard Thanks for writing in.

As long as your OAuth flow starts from /slack/install and the URLs for the OAuth flow are https ones, the new validation should work for you. And, this is the expected way to run the OAuth flow with bolt-js.

If you use some URLs like http://localhost:3000/slack/install, the change may affect because the cookie used for the user state verification has Secure flag. If many other people need http:// URL supports, we may consider adding a new option to enable it. But we've never received the requests in bolt-python and bolt-java.

I hope this was helpful to you.

[pmezard]

Still not have time to investigate properly but here is more context:

• The flow is running in AWS Lambda, with the express receiver. It is not a local setup
• The start URL is generated "manually" by calling installer.generateInstallUrl, in a different part of the application. We are not passing through /install AFAIK.

I guess I will have to take a look at the change and see if I can adjust our code.

[seratch]

@pmezard Ah I see. This makes sense. The new way requires running handleInstallPath() method instead (it generates the same URL plus sets the state value to the browser cookies too). If you use the built-in OAuth flow URL handling, the /slack/install uses the new method internally.

If you have a certain reason to continue directly using generateInstallUrl right now, you can use installerOptions.legacyStateVerification: true option to switch back to v3.10 behavior.

[pmezard]

I am generating the URL that way because I need to inject metadata in the URL. Maybe there is hook in the ExpressReceiver I can use to do that.

[seratch]

bolt-js v3.11 (and its underlying OAuth module v2.5) offers a more flexible way to set additional information through the OAuth flow. You can use beforeRedirection callback in /slack/install and then beforeInstallation callback in /slack/oauth_redirect. Setting 1st party cookies to transfer metadata or whatever may be easier for your use case too.

Refer to the OAuth module's documentation for more details: https://slack.dev/node-slack-sdk/oauth#persisting-data-during-the-oauth-flow

You can pass beforeRedirection function in installPathOptions in bolt-js app. beforeInstalltion is a new addition to callbackOptions.

[xdumaine]

I've picked up maintenance of a slack app that is also using gneerateInstallUrl and I'm also getting the above error. using installerOptions.legacyStateVerification: true doesn't work, unfortunately. Posting in case anyone else has ideas while I investigate. I'll try to post back once I've solved it.

[xdumaine]

I was wrong, that option did fix it, when using 3.11.3. I needed to put in in the installerOptions we were providing to new ExpressReceiver. I had first tried adding installerOptions to the new App If i wasn't in the middle of a hackathon I'd take some more time to try to figure out this code

[cjbara]

If you use some URLs like http://localhost:3000/slack/install, the change may affect because the cookie used for the user state verification has Secure flag. If many other people need http:// URL supports, we may consider adding a new option to enable it. But we've never received the requests in bolt-python and bolt-java.

@seratch is there a workaround using the callbacks for http installations (specifically for local development)? I would love to use the new verification method but it breaks my local installation flow for testing.