Control objective
The OAuth client credentials grant lets a confidential client obtain an access token for the client's own machine authority. It does not represent a human user and must not invent user identity.
Token flow
The client authenticates to the authorization server, requests a bounded scope and resource, receives a short-lived access token, and presents it to the intended resource server. The resource validates issuer, audience, lifetime, and client authority.
Credential operation
Give each workload a distinct client identity. Protect its authentication key, bind tokens to a target where possible, rotate credentials, limit scopes, and record client, resource, policy, and target result. Prefer workload federation over stored secrets when supported.
Failure and residual risk
A shared client collapses workloads. A client secret can be copied and replayed. Broad scopes or missing audience make one token useful elsewhere. Adding a user claim does not make a client token delegated user authority.
Pomerium boundary
Pomerium service accounts support documented non-human access patterns. Operators own client identity, credential custody, token audience, rotation, target validation, and application permissions. Keep human delegation separate when an action is performed for a user.
Evaluation checklist
- Is the client acting only for itself?
- Does each workload have a distinct credential and accountable owner?
- Is the token bound to a narrow resource, scope, audience, and lifetime?
- Can the target reject wrong issuer, audience, expired, and revoked authority?
- Is human delegation represented separately when needed?
