Client Credentials: A Service Acting for Itself

The client credentials grant gives a token to a client acting on its own behalf, with no user involved. The client authenticates directly to the authorization server with its client id and a secret, or a stronger credential such as a signed assertion or mutual TLS, and receives an access token. It fits jobs and services that call an API as themselves, such as a nightly billing run.

No user, no consent. Nobody is redirected and nobody signs in. What the client may do is set when it is registered, by the administrators of the authorization server.

What the token says. Its subject is the client itself. An API must not treat it as a user's token: there is no user whose data it is limited to, so the scopes alone decide what it may do.

Where it fits. Back-end jobs, services calling other services, and partners' servers calling a public API. It is often preferred to a plain API key because the tokens are short-lived, carry scopes, and are issued by the same server that issues every other token.

Where it does not. Any client that cannot keep a secret, such as a mobile app or browser code, and any request made for a particular user, which needs the code flow.

So choose client credentials when the caller is a program acting for itself.