Protocols and how-tos
Service-to-service authentication with the client credentials grant
How the OAuth client credentials grant works, how to authenticate the client, how to scope and rotate secrets, and when to prefer key-based client auth.
The short answer
The client credentials grant (RFC 6749 section 4.4) lets a service obtain an access token as itself, with no user involved. The service authenticates to the token endpoint — with a secret, a signed JWT assertion or mutual TLS — and receives a short-lived token scoped to the APIs it may call. It is the standard replacement for long-lived static API keys.
Sources last reviewed .
Why not just an API key
A static API key is a bearer credential that never expires, is often shared between environments, and is sent on every request. A client credentials token is short-lived, scoped and minted on demand; the long-lived secret goes only to the token endpoint. Rotation and revocation become routine instead of an incident.
Authenticating the client
- client_secret_basic or client_secret_post: simplest, and the secret must be treated like a password — stored in a secrets manager, never in source.
- private_key_jwt (OpenID Connect Core section 9): the client signs an assertion with a private key; the server holds only the public key, so a database leak at the server exposes nothing usable.
- Mutual TLS (RFC 8705): the client certificate authenticates the client and can also bind the issued token.
Operating it
- One client per service per environment; never share credentials across environments.
- Request the narrowest scope and audience for each call.
- Cache the token until shortly before expiry instead of requesting one per call.
- Support two valid secrets at once during rotation so a deploy never needs a coordinated cut-over.
- Sender-constrain the tokens (DPoP or mTLS) when they cross networks you do not control.
In Authreads
How this applies to Authreads
Authreads supports the client credentials grant for machine-to-machine integrations, with secret-based client authentication, and DPoP for sender-constrained machine tokens.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Keep reading
Use cases
Identity for AI agents: delegation, scoping and sender-constrained tokens
Protocols and how-tos
DPoP implementation guide: sender-constrained tokens without mTLS
Protocols and how-tos
OAuth token exchange (RFC 8693) for delegation and impersonation
Glossary: Client credentials grant · Machine identity · Access token
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.