Difference between the "Resource Owner Password Flow" and the "Client Credentials Flow"

The client credentials flow only requires the client_id and client_secret. The Resource Owner flow requires the user's password.

The client credentials flow allows an application to get a token w/out the context of the user.

A good example of this would be the following:

Suppose you're a statistics company called AllStats that has its own user base where each user has their own username and password. AllStats has its own existing website which dogfoods its own API. However, AllStats now wants to release a mobile app.

Since the mobile app will be a 1st party application (see: developed by AllStats), the Resource Owner Password Flow makes a lot of sense. You'll want the user to get a screen (username, password) that flows with the app instead of kicking them over to an auth server (and then back into the app). Users will trust the application when they enter their username/password because it's a 1st party app.

I like to look at the Resource Owner Password Flow as a flow that 1st party app developers would use, whereas the Client Credentials Flow a flow that 3rd party app developers would use.

Imagine if the Facebook app required you to use the Client Credentials Flow instead of just presenting you with a username/password form. Would seem a little odd, yeah?

Now, if imagine you download a 3rd party app that had Facebook integration. I'd imagine you (and most people) would be very leery if the app was prompting you for a username/password instead of using the Client Credential Flow UI.

FWIW, this isn't to say that 1st party apps don't use the Client Credential Flow. But rather to try and paint a real world scenario (and overall generalization) of when Resource Owner Password Flow would be used.

Besides user3287829's answer. I want to add the following.

As the RFC said about Client Credential grant.

The client makes a request to the token endpoint by adding the
following parameters using the "application/x-www-form-urlencoded"
format per Appendix B with a character encoding of UTF-8 in the HTTP
request entity-body:

grant_type REQUIRED. Value MUST be set to "client_credentials".

scope OPTIONAL. The scope of the access request as described by Section 3.3.

The client MUST authenticate with the authorization server as
described in Section 3.2.1.

For example, the client makes the following HTTP request using
transport-layer security (with extra line breaks for display purposes only):

 POST /token HTTP/1.1
 Host: server.example.com
 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
 Content-Type: application/x-www-form-urlencoded

 grant_type=client_credentials

The authorization server MUST authenticate the client.

The client must be registered in the authorization server in advance. and Authorization includes the client credential which will be authenticated by the server.