sfcc client:auth aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa --type client_credentials

Thanks for raising @hnestmann! There are two options I see:

• Change the behaviour of command sfcc client:auth to only accept explicit arguments passed in case you have at least some arguments passed already. In your case, if you are passing client id and secret explicitly it will not read user creds from another source, like from the dw.json but expects them as being passed explicitly as well
• Change command sfcc client:auth and only allow client_credential grant, but not resource_owner_password_credentials grant anymore. Reason being is, that with the Sandbox API now supporting client_credentials grant fully for automation use cases, I don't see any other use case left, which requires resource_owner_password_credentials anymore. Note, we would still allow a user to authenticate interactively using sfcc-ci auth:login

In any case, both options above are breaking changes and would have to walk into a new major version.

Thoughts?

Adding --type client_credentials option for sfcc client:auth (as @hnestmann mentioned) maybe the best solution...

+1 for resolving this issue, in our use case during local development we use JS API scripts whenever possible, but instance:export is not supported (another enhancement to report 😄), so we have to use client:auth that inevitably uses user from dw.json.
@tobiaslohr could you consider backward compatible change like the additional flag mentioned, to release it for 2.x version?

Can we get one of these fixes merged?
This has been open for two years, and it's completely broken when trying to use client:auth if the password in your dw.json is an access key instead of your account manager password.