The Client Credentials Flow

Machine-to-machine access

Some integrations have no human in the loop at all: a nightly synchronisation job, a backend webhook processor, or one microservice calling another inside your own estate. For these, the client credentials flow lets the application authenticate as itself, exchanging its own credentials directly for an access token without any user involvement.

There is no redirect, no login screen, and no consent prompt, because the service is acting purely on its own behalf rather than for a user whose permission must be sought. That simplicity is the point: the flow strips OAuth down to the parts that make sense when identity belongs to an application rather than a person. This is the standard pattern for server-side Merion API jobs, and it is usually a better choice than a static API key for the same task.

How it works

The service sends its client identifier and secret to the token endpoint, requesting the specific scopes it needs for the job. The authorisation server validates those credentials and, if they check out, returns an access token directly. There is no authorisation code and no intermediate redirect, because there is no user to send through a browser.

POST /token
grant_type=client_credentials
&scope=...

Because no user is involved, the resulting token represents the application itself and carries whatever permissions that application has been granted. Treat the credentials used here as highly sensitive, on a par with a database password: anyone who holds them can mint tokens with the service's full privileges, at any time, until those credentials are rotated or revoked.

Scoping service tokens

A service token should request only the scopes that its particular task genuinely requires, and no more. A read-only reporting job has no business holding write or delete permissions, and granting them anyway simply enlarges the damage a leak could cause. Narrow scopes keep the blast radius small if the token, or the credentials behind it, are ever exposed.

This is the principle of least privilege applied to machines rather than people, and it is just as important there. Service credentials are often long-lived and run unattended, so an over-privileged one can sit quietly as a liability for months. We expand on this thinking in Least Privilege for API Access, which every backend integration should follow as a matter of routine.

Operational care

Client credentials are long-lived by nature, so protecting them operationally is paramount and cannot be an afterthought. Store them in a dedicated secrets manager rather than in source control or a configuration file checked into a repository, and rotate them on a regular schedule. Crucially, issue a distinct credential for each integration so that one compromise does not force a fleet-wide reset and outage.

Separate credentials also let you monitor and revoke each integration independently, which makes incident response far less disruptive. For detailed storage and rotation guidance, see Securing Client Secrets. The healthiest pattern pairs short-lived access tokens, which limit exposure in time, with carefully guarded long-lived credentials behind them.