feat(integrations): add TwoStep as a new auth_mode for Perimeter 81

[hassan254-prog]

Describe your changes

• Add support for perimeter81

Issue ticket number and link

EXT-195

The flow is somewhat custom, where we send a single api_key and receive an access_token, which can later be used for authentication by passing the token in the headers like this: Authorization: Bearer <ACCESS_TOKEN>. I anticipate the list will continue to grow as we add support for more of these. I’m open to suggestions on how we can better handle these scenarios.

curl -X 'POST' -H 'Content-Type: application/json' \
-d '{
  "grantType": "api_key",
  "apiKey": "<API_KEY>"
}' 'https://api.perimeter81.com/api/v1/auth/authorize'


{
   "data":{
      "tokenType":"bearer",
      "accessToken":"<ACCESS_TOKEN>",
      "accessTokenExpire":<TOKEN_EXPIRE_TIME>
   }
}

[bodinsamuel]

I feel like we could go with some if in the code instead of entirely dedicated auth strategy, but at the same time it keeps them well isolated. I don't know

[hassan254-prog]

I have run tests locally using a mock API server based on the provider's API documentation, and tests were successful.

[TBonnin]

it is yet another flavor of a 2-steps token based authentication. I am a little bit worried about adding a new credentials type every single time. I wonder if we could define a more generic authMode. We already have token_url, we would need a additional token_url_headers but do we need anything else in the providers.yaml

[TBonnin]

this works only because no other credentials has a attribute called api_key in snake case. It is very fragile and might be a source of bugs if more credentials with an api_key attribute are added. This PR is probably not the place to refactor but a good refactoring of this function would be welcome. For instance credentials could bevalidated with the help of zod schemas

[hassan254-prog]

it is yet another flavor of a 2-steps token based authentication. I am a little bit worried about adding a new credentials type every single time. I wonder if we could define a more generic authMode. We already have token_url, we would need a additional token_url_headers but do we need anything else in the providers.yaml

We can also define the various fields i.e api_key for perimeter81, in the providers.

[hassan254-prog]

@TBonnin, @bodinsamuel,

I don't know if I have done too much here, but after working on this, I believe we can comfortably merge BILL, TABLEAU, and other future integrations with this kind of flavor. I will open another PR to refactor the above convertCredentialsToConfig. I will need help with renaming the auth_mode. What do you think about the implementation?

This will now enable us to have such:

foo:
    display_name: Foo
    categories:
        - productivity
    auth_mode: TWOSTEP
    proxy:
        base_url: https://api.perimeter81.com/api/rest
    token_url: https://api.${connectionConfig.domain}.com/api/v1/auth/authorize
    token_params: 
        credentials:
            apiKey: ${credential.apiKey}
            grantType: api_key
            site:
                content_url: ${credential.contentUrl}
    token_headers:
        Content-Type: application/json
    token_response:
        token: data.accessToken #Dynamically access the token 
        token_expiration: data.accessTokenExpire #Dynamically access the token expiration date 
        token_expiration_formula: expireAt | expireIn # Same for this we can dynamically pick the formula to calculate the expire at value
    token_expires_in_ms: 36000   # Help us define this if provider has only mentioned in docs but not included in raw cred data
   

Future works for this:

• Dynamically add authentication in proxy headers for this, i.e:

proxy:
    base_url: https://api.perimeter81.com/api/rest
    authentication_header: X-tableau-Auth ${token}

• Come up with a way of how we can dynamically add zod validation.

[TBonnin]

love it. Regarding the naming I feel it should be called TBA for token based authentication and the existing TBA should be renamed NetsuiteTBA because it is very much specific to Netsuite. What do you think?

[hassan254-prog]

love it. Regarding the naming I feel it should be called TBA for token based authentication and the existing TBA should be renamed NetsuiteTBA because it is very much specific to Netsuite. What do you think?

Yes I agree, that would be a better naming strategy. My worry is after renaming would it be a breaking change to the existing TBA connections? Maybe we can start by checking if there are any connections in prod environment.

[bodinsamuel]

Thanks for the grit on this, I haven't tested but looks correct. Last batch of comments 👌🏻

[khaliqgant]

love it. Regarding the naming I feel it should be called TBA for token based authentication and the existing TBA should be renamed NetsuiteTBA because it is very much specific to Netsuite. What do you think?

Yes I agree, that would be a better naming strategy. My worry is after renaming would it be a breaking change to the existing TBA connections? Maybe we can start by checking if there are any connections in prod environment.

There are TBA integrations on prod, so let's hold off on renaming TBA for now.