OAuth2 - Benefits for using Grant-Type:Password for machine-to-machine web-service calls

Question

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 any more 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?

Answer 1

As described in the section 4.3 of the RFC6749 (here)

The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application. The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.

It is also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token

In sum, you can use it if you have a strong trust relationship with the client application OR to "update" legacy applications in such a way as to avoid the use of authorization methods in the original HTTP spec and to benefit from stuff like scopes, expirations that you cannot guarantee with a simple basic auth

So to answer your question: No, you are missing nothing, the Grant-Type is not suitable for modern applications.