Supporting /v2/token Auth Url

[ahome-tm]

Introduction:
Hello! I am just starting out with integrating with SFMC for my company and I am trying to use this SDK along with FuelSDK-Node-REST. At the start I am just trying to understand the best ways I can use these SDKs.

Task:
Easily Initialize this class for use. At the moment I feel like I'm really doing some wonky things to be able to make this Class work how I need it to. I think the root of my issues come from this class seems to be set up to work with the /v1/requestToken route for authentication, but I do not have a legacy package as such I need to be able to use /v2/token and the syntax between these to varies. Through a lot of digging into how the code works and lots of trial an error I can use the /v2 route.

My usage:
To just have a simple initialization process this how I get getAccessToken to work.

// Simple Initialization 
const options = {
  clientId: myClientId,
  clientSecret: myClientSecret,
  authUrl: authUrl // https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
}

const AuthClient = new FuelAuth(options)
const authOptions = {
      force: true,
      json: {
        grant_type: 'client_credentials',
        client_id: myClientId,
        client_secret: myClientSecret
      }
    }
    AuthRest.getAccessToken(authOptions)
      .then(resp => {
           // I can see a valid response and my access token is under access_token
      })
      .catch(err => {
          // handle error
      })

If I wanted to make sure not to pass any options to getAccessToken, then this is what I did to get it to work.

// Complicated Initialization 
const options = {
  clientId: myClientId,
  clientSecret: myClientSecret,
  authUrl: authUrl, // https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
  globalReqOptions: {
    json: {
      grant_type: 'client_credentials',
      client_id: myClientId,
      client_secret: myClientSecret
    }
  }

const AuthClient = new FuelAuth(options)
    AuthRest.getAccessToken()
      .then(resp => {
           // I can see a valid response and my access token is under access_token
      })
      .catch(err => {
          // handle error
      })

The Observation:
The module needs to be updated to be able to fluidly use both routes without much change to the client using this already. I think by changing the format of options in the constructor or even how the request calls are made will help make this more user friendly. I also think it should give a standard response to whoever is asking for the token. (I have some understanding how the base class is working, so I am also trying to think of the best way to achieve this.)

Takeaway:
The way things are now really do not allow for me to use FuelSDK-Node-Rest fluidly as I would like. The fact that FuelSDK-Node-Rest makes assumptions on the format of the response is where I am getting blocked. I cannot make any calls using the REST module since I get a Error: No access token which is happening because of how that code is looking for the access token. It expects accessToken and since v2 returns access_token that check for the token fails.

Hoping to get more insight on this!

Regards

[apotek]

It expects accessToken and since v2 returns access_token that check for the token fails.

I've seen this too. And this seems like a pretty straightforward thing to fix.

[apotek]

Looks like this is being addressed here? #76