Client Credentials Grant

What is the client credentials grant?

The client credentials grant is the OAuth 2.0 flow designed for machine-to-machine (M2M) authentication — when a service, script, or backend application needs to access an API as itself, with no human user involved. The application authenticates directly using its own credentials (a client ID and client secret) and receives an access token it can use to call APIs. There’s no user, no login prompt, no browser redirect, and no user-consent step — because there’s no user in the picture at all. It’s the right OAuth flow for backend services talking to other backend services, scheduled jobs, daemons, and any automated system that acts on its own authority rather than on behalf of a person.

How it differs from the user-facing OAuth flows

Understanding client credentials means understanding what it’s not, because OAuth’s other flows exist for a fundamentally different purpose. Most OAuth flows — the Authorization Code flow (with PKCE) — are about delegated authorization: a user grants a third-party app permission to access the user’s resources (the “Sign in with Google” / “allow this app to access your calendar” pattern), which requires the user to authenticate, see a consent screen, and be redirected through their identity provider. The client credentials grant strips all of that away because it answers a different question: not “may this app act on behalf of this user?” but “is this service allowed to access this API on its own behalf?” So the flow is simple — the client sends its client ID and secret to the authorization server’s token endpoint, the server validates them, and returns an access token (typically a JWT) scoped to what that client is permitted to do. No redirects, no user interaction. Using the wrong flow is a common and consequential mistake: trying to force a user-delegation flow for a backend job (awkward and often insecure), or — worse — using client credentials where you actually needed to act on behalf of a specific user (losing the user-identity and per-user authorization the situation required). The rule of thumb: user involved and you’re accessing their data → Authorization Code + PKCE; no user, service acting as itself → client credentials.

The security realities — it’s a shared secret

Because the client credentials grant authenticates with a long-lived client secret, it inherits all the risks of shared secrets — and mishandling that secret is where things go wrong. The security disciplines that matter: the client secret must be protected like the powerful credential it is — stored in a secrets manager (not hardcoded in source, not committed to Git, not baked into a container image or client-side code where it can be extracted), transmitted only over TLS, and rotated periodically and immediately on suspected exposure (a leaked client secret is a valid credential until revoked, exactly like a leaked API key). Apply least privilege via scopes: the access token should grant only the specific permissions the service needs, so a compromised credential has limited blast radius rather than broad access. And critically, client credentials is only appropriate for confidential clients — backend services that can actually keep a secret secret. It is never appropriate for browser-based SPAs or mobile apps, because they cannot securely store a client secret (anyone can extract it from client-side code), so using client credentials there hands the secret to attackers; those clients use the Authorization Code flow with PKCE instead. The recurring mistakes: leaking the client secret through insecure storage, over-scoping the token so a compromise grants too much, never rotating credentials, and — the architectural error — using the client credentials flow from clients that can’t protect a secret.

What people get wrong

• Using it where user context is needed — client credentials authenticates the service as itself; if you need to act on a specific user’s behalf with their permissions, use Authorization Code + PKCE.
• Leaking or never rotating the secret: the client secret is a long-lived credential — hardcoding it, committing it, or embedding it in client-side code exposes it; store it in a secrets manager and rotate it.
• Using it from SPAs/mobile apps — public clients can’t keep a secret secret, so client credentials there just hands attackers the credential; browser and mobile apps must use PKCE flows.

Primary source: OAuth 2.0 Client Credentials Grant (RFC 6749 §4.4)