In that case -
- Client credentials would need to be sent with every request to every server-side app/system that can present resources.
- There would be no expiry and no scope limitation on any specific session.
- 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.