OAuth: client credentials vs tokens

Question

Wouldn't it be much simpler and virtually equally secure to replace tokens by pure client credentials?

Client credentials wouldn't expire and resource owners would always be able to modify their access control matrix to revoke any privilege any time.

Answer 1

In that case -

1. Client credentials would need to be sent with every request to every server-side app/system that can present resources.
2. There would be no expiry and no scope limitation on any specific session.
3. It would be just like legacy basic auth, with all its drawbacks and benefits (simplicity)

In the OAuth client credentials flow, 'client' refers to a client application and not necessarily the resource owner (end user). In some cases, like mobile apps, both are almost the same, as there is usually a single user of the client. Thus, for a simple application, replacing an access token by repeatedly sending client credentials may be a suitable substitute. However, for any distributed application where APIs and resources are distributed across different domains/servers/applications, having a central token endpoint is more scalable and more secure just by virtue of being a single point.

While Facebook has two-legged OAuth for end users (resource owners) using Facebook apps (clients), Facebook provides access tokens to Facebook apps via OAuth client credentials workflow.