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.

Answer 3

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.

Answer 4

additionally, in terms of auditing, resource owner is better way, because you can identify by access_token which specific user is calling your api through the client application, while client_credential identifies only the application client

Answer 5

Other answers explain well about the "Resource Owner Password Flow". So I will explain the "Client_credentials" grant type flow. In the "Client_credentials" flow client_id and client_secret are used to authenticate the Client not the Resource owner. So you can ask without the Resource owner authentication how a client (Most of the time a application) will obtain access to the resources. That's a good question. The answer is, here Client will get access_token for it's own resources or access to an user-resource which is already given under this client_id. client_secret and client_id generation is a most of the time a manual process. For example look at this -> Create a client ID and client secret for google APIs. In the Client secret creation step you are creating authentication credential for your application.