I'm using a 3rd party service developed by the Experian Credit Bureau. Looking at their documentation, they are using OAuth2 & are expecting Grant_type: password in order for external developers to obtain an access_token. So, the developer must pass their username/password/client id & client secret (the last 2 of which you create and retrieve via the developer portal)

To get the access_token you would call the following endpoint;

curl -X POST https://sandbox-us-api.experian.com/oauth2/v1/token \
  -H 'Accept: application/json' \
  -H 'Content-type: application/json' \
  -H 'Grant_type: password' \
  -d '{"username": "<USERNAME>","password": "<PASSWORD>","client_id": "<CLIENT_ID>","client_secret": "<CLIENT_SECRET>"}'

Everything works fine and i've no problem obtaining the access token however i don't understand how this is anymore secure than simply passing a username/password (which oauth2 was designed to avoid); These services are normally machine-to-machine invoked so you will need to have the credentials stored on the system calling their services so if a bad actor was to steal these then they can obtain the client_id & client_secret by simply logging into the developer portal.

They are using Okta who says that password grants should only ever be used for trusted internal apps but this isn't the use-case for these services - we are not internal nor trusted.

Alternatively, I could architect so that the calling machine only works with the access_token and refresh_token however that means you need to re-authenticate when the refresh_token expires (24 hours) which in my case the service is only invoked once per week - this means i would have to reset the access_token manually each week.

What am i missing that makes this approach more secure than a simple username/password exchange?