As I read OAuth 2.0 recommends against using the password grant type and it is being removed in the OAuth 2.1 update. But what is the proper solution then when you have a machine-to-machine communication channel?
In my case I have a couple of Powershell scripts that get an access token used in subsequent API calls. So they are requesting an access token by providing the username and password of my applicative user which has its own claims and thus gets access to a limited set of API's.
I could use a client_credentials flow instead, but then I am not authenticating an actual batch user, just my client. Which might not give me the claims I am looking for. And as a follow-up question, how is hardcoding the client id + secret any different from hardcoding the user + password?
The client credentials flow is the correct option for backend initiated flows, such as a scheduled job, when no user is involved.
Alternatively, if your scripts are run interactively by admin users, a native code flow could be used by the script, which is a console (native) client. Doing so could issue different claims based on the script user.
Regardless of the flow you can still use claims. The client's scope triggers inclusion of the claims. Issuing claims doesn't have to involve a user.
As an example, consider a nightly job that checks for unpaid invoices. This could use a scope like invoices:reconcile that isn't used by any other client. Using this scope might also trigger inclusion of claims such as region=USA, where the claims are calculated based on some logic applied at the time of token issuance.
Some authorization servers may have limitations on how claims are issued for the client credentials flow, meaning you may need to resort to workarounds. There is no such limitation in OAuth 2.0 itself though, so I always like to encourage the most standards based designs.
CLIENT CREDENTIALS FLOW
It is possible to use one of these methods for the client credentials flow, that supports multiple callers, with only a single client registration. Based on properties received, different claims can be issued:
Separate clients is usually recommended though. It ensures that, if client A's credential is compromised, you can can deny access without affecting client B.