`invalid_token`: Authorization errors with Sandbox API

Hey folks,

Thanks so much for this great tool!

I’m scripting management of our on-demand instances and having trouble using the access_token returned by sfcc-ci auth:client to do it.

As I understand it, to allow my script to manage our On Demand instances, I must:

1. Create an API Key in Account Manager, setting appropriate scopes and noting its key and password as per this article
2. Install this package
3. Run something like:

   sfcc-ci auth:client "${AM_API_CLIENT_KEY}" "${AM_API_CLIENT_PASSWORD}"
   sfcc-ci sandboxes:list
   

So, following those steps, I first use my API Client to get an access_token:

sfcc-ci auth:client "${AM_API_CLIENT_KEY}" "${AM_API_CLIENT_PASSWORD}"

Which succeeds returning:

{
    "access_token": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
    "scope": "tenantFilter profile roles",
    "token_type": "Bearer",
    "expires_in": 1799 
}

Then I try to list the sandboxes:

sfcc-ci sandbox:list

Which fails with the following error:

{"statusCode": "401",
     "body":
      { "error": "invalid_token",
        "error_description": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" }
}

🤔

I should note that if I try the same flow using auth:login rather than auth:client, things work:

sfcc-ci auth:login

# Browser opens and successfully auths, CLI acks auth.

sfcc-ci sandbox:list

# CLI successfully lists sandbox instances

This flow wouldn’t work however as the intention is to just run a script, not have someone click buttons to auth things 😃

Any ideas?

Thanks so much.

[tobiaslohr]

Hi @johnboxall, thanks for the kudos and the feedback!

There are two options on how to authenticate with the CLI, the interactive use (a human using the tool) or the automation use (for automated scripts or system to system integrations).

The command sfcc-ci auth:login "${AM_API_CLIENT_KEY}" runs an Oauth implicit flow (for interactive use) and the (Account Manager) user must authenticate him/herself via the Account Manager login (see sfcc-ci auth:login --help for details and examples).

The command sfcc-ci client:auth runs different Oauth flows for automation (see sfcc-ci client:auth --help for details and examples). In case you want to manage sandboxes for example, you still require an authenticated user (and thus provide Account Manager user credentials) to the command:

sfcc-ci client:auth "${AM_API_CLIENT_KEY}" "${AM_API_CLIENT_PASSWORD}" "${AM_USER}" "${AM_PWD}"

This runs an Oauth resource_owner_password_credentials grant.

sfcc-ci client:auth "${AM_API_CLIENT_KEY}" "${AM_API_CLIENT_PASSWORD}" without user credentials runs an Oauth client_credentials grant. This can be used for some, but not all (!) of the CLI commands. For example, you make use of the Data APIs on a B2C instance with only a client_credentials grant. However, for other CLI commands (like sandbox management, or Account Manager user and role management) you’d have to provide Account Manager user credentials. This is the also reason why you’e command sfcc-ci sandbox:list fails.

If you want to automate the sandbox management, it may be a good practice to use a dedicated Account Manager user with only the Sandbox API User role and then to disable 2FA for the Sandbox API User role in your org in Account Manager. This prevents you from being caught with 2FA for your automation user. Other (human) users typically have other roles in Account Manager, which you should have 2FA activated for, thus those user still have to do 2FA if they manage sandboxes via the CLI interactively.

Hope this helps and answers your question!

[tobiaslohr]

Thanks @tobiaschudalla.

That’s a different Tobias 😉

Given your answer, my understanding is that it is not possible to interact with the Sandbox API using an access_token provided by sfcc-ci client:auth.

Not, that is not true and the understanding is wrong. Of course the access_token obtained by the command sfcc-ci client:auth with API credentials and user credentials can be used to access resources on the Sandbox API server to manage sandboxes.

• Currently, using the JavaScript API, it is not possible to implement the above flow. obtainToken is not exported from lib/auth and the exported methods do not accept both sets of credentials and a callback argument. To resolve this you could either export obtainToken or extend the signature of api.auth.

That is correct. The first and foremost usage for this tool is the CLI. The JavaScript API was never a first class citizen. If there are any JavaScript API enhancements, like the one mentioned, feel free to create an issue.

• Using a user account means we’ll need to regularly rotate credentials which is a pain ;P Super meta feedback: I don’t really understand why this API requires an Oauth grant (and more specifically why it would require the user credentials as opposed to the other grant). In future town, it would be nice if I could do what I need to with just an API Key + Secret.

Yes, yes and yes. The CLI is only consuming the APIs being available, and implements the authentication flows (Oauth flows) required to do some. Some APIs require only an API client (like some of the OCAPI resources) other APIs (like Sandbox Management or Account Manager APIs for User management) require a user context hence user credentials. The user context is required right now, also for automation use case. For sure, the renewal of the user credentials is odd. The product team is working on enhancements to the APIs to streamline the API access and permissions. That may result in a complete drop of the user context in the future.