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

Question

The difference between the "Resource Owner Password Flow" and the "Client Credentials Flow" seems unclear to me. The former seems to forward the password credentials to the server for verification, while the latter does authenticate with the server in some way too, but the spec doesn't specify what method is used here. Is this flow designed for cookie sessions? The spec doesn't really provide a clear use case.

From the OAuth 2.0 spec:

 +---------+                                  +---------------+  |         |                                  |               |  |         |>--(A)- Client Authentication --->| Authorization |  | Client  |                                  |     Server    |  |         |<--(B)---- Access Token ---------<|               |  |         |                                  |               |  +---------+                                  +---------------+                   Figure 6: Client Credentials Flow 

and

 +----------+  | Resource |  |  Owner   |  |          |  +----------+       v       |    Resource Owner      (A) Password Credentials       |       v  +---------+                                  +---------------+  |         |>--(B)---- Resource Owner ------->|               |  |         |         Password Credentials     | Authorization |  | Client  |                                  |     Server    |  |         |<--(C)---- Access Token ---------<|               |  |         |    (w/ Optional Refresh Token)   |               |  +---------+                                  +---------------+          Figure 5: Resource Owner Password Credentials Flow 

Answer 1

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.

Answer 2

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.