feat(integrations): add support for salesforce cdp

[hassan254-prog]

Describe the problem and your solution

Add support for Saleforce Data Cloud

Testing instructions (skip if just adding/editing providers)

Here’s a more grammatically polished version:

This provider supports the TWO_STEP authentication mode but requires some changes to fully implement it. Specifically, a second request is needed after obtaining the initial access_token from Salesforce to generate the Salesforce Data Cloud (CDP) access_token. Since I couldn't test this locally with Data Cloud, I created a mock server to simulate responses from both Salesforce and Data Cloud, similar to the approach with Perimeter81. The process of generating the encoded JWT (assertion) is somewhat technical for users, so I also included a script to enable offline generation, as we did with SharePoint Online v1.

[linear]

EXT-218 Add support for Salesforce CDP

[TBonnin]

Yet another auth flow :/
I wish that instead of TWO_STEP we introduced a MULTI_STEP mode that takes a list of request params because now we have a TWO_STEPS provider which has 3 steps :(
Is it too late to refactor TWO_STEP? @hassan254-prog

[hassan254-prog]

Yet another auth flow :/ I wish that instead of TWO_STEP we introduced a MULTI_STEP mode that takes a list of request params because now we have a TWO_STEPS provider which has 3 steps :( Is it too late to refactor TWO_STEP? @hassan254-prog

TWO_STEP has proven to be quite useful for some of the more complex authentication modes from the provider 😅 🙌 . No, it’s not too late to refactor, as the main logic revolves around how we save the access_token and retrieve the expireAt value from the response. So, we should be fine to proceed with the refactor. However, I will need to review and test this further on my end. Do we anticipate having a provider with more than three steps in the future? Or work with the max current steps we have at the moment, three.

[TBonnin]

Do we anticipate having a provider with more than three steps in the future? Or work with the max current steps we have at the moment, three.

I stopped trying to anticipate how providers implement authentication. 😆 So many slightly different implementations it is hard to foresee anything.
I don't know how busy you are and how urgent it is to support this flow. I'll let you and @khaliqgant decide about the necessity of the refactor.

[bodinsamuel]

Auth is definitely becoming harder. Looks good, some open questions

[bodinsamuel]

why not simply start at 0?

[hassan254-prog]

The loop starts at 1 and accesses provider.additional_steps[stepIndex - 1] to align with the step numbering convention used in providers.yaml. Starting from 1 ensures consistency in configuration, making it more intuitive for human readability—e.g., referencing step1 instead of step0. This approach maintains a natural mapping between the loop index and the defined steps in providers.yaml.

[bodinsamuel]

step1 is what in this context?

[hassan254-prog]

step1 refers to the response from the initial request made before any additional steps, if provided. In subsequent steps, parameters are accessed dynamically using step{request_number}.