How to do AuthenticationType.OAuth2 but slightly different?

I am working on creating a pack and the service it needs to make requests to uses OAuth2, but expects client_secret to be sent in the body of the POST request to the token endpoint.

I saw AuthenticationType.CustomAuthentication, but I think it cannot be used to support this kind of authentication… am I right that for this service, I cannot currently implement a pack that authenticates this way? Or am I missing something?

This is when I run coda auth from the cli. It appears the library (client-oauth2) used to make the request to the token endpoint won’t allow that.

Thanks for any guidance.

Hi William - It’s fairly standard to require the client_secret in the request body, and a lot of major API providers (including Google) do so. Coda already sends the client_secret in the request body on token requests, so you should be all set. Were you running into an issue?

Hi Eric,

Thanks for your help. Probably just a local issue then :slight_smile:

To reproduce the issue I run:

npx coda auth pack.ts

With this minimum pack to reproduce the issue:

import * as coda from '@codahq/packs-sdk';

export const pack = coda.newPack();

pack.addNetworkDomain('api.box.com');

pack.setUserAuthentication({
    type: coda.AuthenticationType.OAuth2,
    authorizationUrl: 'https://account.box.com/api/oauth2/authorize',
    tokenUrl: 'https://api.box.com/oauth2/token',
});

The coda auth tool makes this request to the token URL (I hid the auth header and code values).

curl -H "accept: application/json, application/x-www-form-urlencoded" -H "content-type: application/x-www-form-urlencoded" -H "authorization: Basic 12345 -H "user-agent: Popsicle (https://github.com/serviejs/popsicle)" -H "Host: api.box.com" --data-binary "code=67890&grant_type=authorization_code&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Foauth" --compressed "https://api.box.com/oauth2/token"

Is there a way to instead make coda auth send client_id/client_secret in the body of the request to the token URL?

@William_Riley-Land - Ah, it does seem like our CLI doesn’t do auth the same way as the server, which is what is causing the issue here. I’ve opened a bug with the engineering team to take a look into this.