Skip to main content
Identity Authority
Category: OAuth & OIDC

Client Credentials Grant

Also known as: Client Credentials Flow
Simply put

The Client Credentials Grant is a way for an application or service to obtain access to resources on its own behalf, without any user being involved. Instead of acting for a person, the software authenticates using its own credentials to get an access token. It is typically used for machine-to-machine communication, such as one backend service calling another.

Formal definition

The Client Credentials Grant is an OAuth 2.0 authorization grant type in which a client authenticates directly to the authorization server using its own credentials and, on success, receives an access token to access resources on its own behalf rather than on behalf of an end user. Because no resource owner participates, this grant is intended for confidential clients that are effectively acting as their own resource owner, typically machine-to-machine (M2M) scenarios. Note that this is a delegated authorization flow within OAuth 2.0, not an end-user authentication mechanism; no user is authenticated and, in most deployments, no ID token or refresh token is issued (an access token alone is returned). Client authentication method (for example, client secret or other confidential-client credentials) and the specifics of token content, scope, and lifetime depend on the authorization server configuration and profile.

Why it matters

The Client Credentials Grant addresses a category of access that user-centric flows cannot: machine-to-machine (M2M) communication where no human is present to authenticate or consent. As architectures shift toward microservices, automated pipelines, and backend integrations, the volume of non-human identities requesting access has grown substantially, and this grant is one of the primary OAuth 2.0 mechanisms for issuing those services scoped access tokens on their own behalf. Getting it right matters because these credentials often operate continuously and unattended, without the interactive checks that surround human sessions.

The security implications follow directly from that autonomy. Because the client authenticates with its own credentials and effectively acts as its own resource owner, the client credential (for example, a client secret) becomes a high-value target: whoever holds it can obtain access tokens directly. Poor secret hygiene, hardcoded secrets in source code, secrets checked into repositories, overly broad scopes, or long-lived credentials that are never rotated, converts a routine M2M integration into a standing exposure. Unlike a user-driven flow, there is no end user to notice anomalous prompts, so compromise can persist quietly.

It is equally important to understand what this grant does not do. The Client Credentials Grant is a delegated authorization flow, not an end-user authentication mechanism; no user is identified or authenticated, and in most deployments no ID token or refresh token is issued. Teams that mistakenly treat a successfully returned access token as evidence that a user was authenticated introduce a fundamental design error. Reserving this grant strictly for service identities, and choosing user-centric authentication flows (typically layered with OpenID Connect) when a person must be verified, keeps authentication and authorization concerns properly separated.

Who it's relevant to

Security Architects
Architects designing service-to-service communication choose the Client Credentials Grant when a backend needs access on its own behalf with no user in the loop. They must scope this grant to confidential clients that can protect credentials, define appropriate token scopes and lifetimes, and ensure it is never repurposed as an authentication mechanism, since no user is authenticated by this flow.
IAM Engineers
Engineers implementing and configuring flows against authorization servers (for example, using vendor guidance from providers such as Okta, Ping, or Microsoft Entra) handle client registration, client authentication method selection, and token endpoint behavior. They should account for the fact that behavior, client authentication method, token content, scope, and lifetime, depends on the authorization server configuration and profile.
System Administrators and Platform Operators
Operators who run the backend services relying on this grant are responsible for storing client credentials securely, rotating them, and monitoring token usage. Because these are unattended machine identities with no interactive user to detect misuse, operational discipline around secret management is central to keeping the flow safe.
Identity Governance Leads
Governance teams increasingly must account for non-human identities. Clients using this grant represent service accounts that should be inventoried, assigned owners, and periodically reviewed for whether their granted scopes remain necessary, applying lifecycle and access-review discipline to machine identities as well as human ones.

Inside Client Credentials Grant

OAuth 2.0 grant type
The Client Credentials Grant is one of the authorization grant types defined in the OAuth 2.0 framework, used for machine-to-machine (M2M) scenarios where the client acts on its own behalf rather than on behalf of an end user.
Client authentication
The client authenticates directly to the authorization server's token endpoint using its own credentials, such as a client ID and client secret, or in many deployments a stronger method like a signed client assertion (private_key_jwt) or mutual TLS.
Token endpoint request
The client sends a request to the token endpoint with grant_type=client_credentials, optionally including a scope parameter to indicate the requested authorizations.
Access token issuance
On successful client authentication and authorization, the authorization server returns an access token. This token represents the client's own granted permissions, not those of any delegating user.
Absence of user context
Because no resource owner is involved, there is typically no ID token and no refresh token issued; the flow is a pure delegated authorization mechanism for the client itself, with no end-user authentication taking place.
Scope-based authorization
Requested scopes determine what the resulting access token permits at the resource server, subject to what the authorization server is configured to grant to that client.

Common questions

Answers to the questions practitioners most commonly ask about Client Credentials Grant.

Does the Client Credentials Grant authenticate a user?
No. The Client Credentials Grant is an OAuth 2.0 authorization flow in which the client authenticates itself as an application, not a human user. There is no resource owner present in this flow, so no user identity is established. The grant is designed for machine-to-machine (M2M) scenarios where the client acts on its own behalf rather than on behalf of a user. Because no user is authenticated, this grant typically does not produce an ID token (an OIDC construct); it yields an access token representing the client itself. If you need to authenticate a user, you should use an authentication layer such as OpenID Connect on top of an appropriate user-facing flow, not the Client Credentials Grant.
Is issuing an access token to the client the same as authorizing it for everything?
No. Receiving an access token via the Client Credentials Grant confirms that the client successfully authenticated itself and was granted a token, but it does not by itself define what the client may do. Authorization is still determined by the scopes, audiences, and any policy constraints associated with that token, and ultimately enforced at the protected resource. In most deployments the authorization server issues only the scopes the client is entitled to, and the resource server (acting as or consulting a policy enforcement point) validates the token and evaluates whether the requested action is permitted. Client authentication and the resulting authorization decision remain separate steps.
How should a confidential client authenticate itself when requesting a token with this grant?
The Client Credentials Grant requires the client to authenticate to the authorization server's token endpoint, and it is generally intended for confidential clients that can protect their credentials. Common client authentication methods include a client secret (for example via HTTP Basic or POST parameters) and, in more security-sensitive deployments, private key JWT (client assertions) or mutual TLS. The exact methods supported depend on the authorization server and the profiles it implements. Public clients that cannot safeguard a secret are typically not suitable for this grant. Consult your authorization server's documentation for which client authentication methods are available and recommended.
Should tokens obtained through the Client Credentials Grant include a refresh token?
Typically no. Refresh tokens are generally not issued with the Client Credentials Grant, because the client can simply re-authenticate with its own credentials to obtain a new access token when the current one expires. Since there is no user session to preserve, the usual rationale for a refresh token does not apply. Behavior can vary by authorization server, but in most deployments the client is expected to request a fresh token from the token endpoint as needed rather than relying on a refresh token.
How can I scope and audience-restrict tokens issued through this grant to limit blast radius?
In most deployments you constrain what a client-credentials access token can do by configuring the scopes the client is permitted to request and by setting an audience (or resource indicator) so the token is only valid at the intended protected resource. Granting each client only the minimal scopes it needs, and issuing distinct clients per service rather than sharing one client identity, helps limit the blast radius if a credential is compromised. Resource servers should validate both the scope and audience claims during token validation. The specific configuration options and claim names depend on the authorization server and profile in use.
How should client secrets used with this grant be stored and rotated?
Because the grant depends on the confidentiality of the client's credentials, those credentials should be protected like any other high-value secret, for example in a secrets manager or hardware-backed store rather than embedded in source code or configuration checked into version control. Rotating credentials periodically, and supporting overlapping validity during rotation, helps avoid outages when secrets change. Where the authorization server supports it, stronger client authentication methods such as private key JWT or mutual TLS can reduce reliance on a shared static secret. The available storage integrations and rotation mechanisms depend on your platform and authorization server.

Common misconceptions

The Client Credentials Grant authenticates a user.
It does not authenticate any end user. OAuth 2.0 is a delegated authorization framework, and this grant authenticates the client application to the authorization server and authorizes the client acting on its own behalf. There is no resource owner and no user identity involved; use OpenID Connect if user authentication is required.
A refresh token should be issued with the Client Credentials Grant.
In most deployments no refresh token is issued, because the client can simply re-authenticate with its own credentials to obtain a new access token when the current one expires. Refresh tokens are typically associated with grants that carry a user context.
The issued access token, being signed, is safe to expose.
A signed token proves integrity and origin but is not the same as being encrypted; its claims may be readable if it is a self-contained JWT. The token still grants the client's authorizations and must be protected as a secret in transit and at rest, regardless of signing.

Best practices

Restrict the Client Credentials Grant to machine-to-machine use cases and do not use it where an end user must be authenticated; choose OpenID Connect flows for user authentication instead.
Prefer stronger client authentication methods such as private_key_jwt or mutual TLS over a shared client secret where the authorization server and deployment support it.
Request the least-privilege set of scopes for each client and configure the authorization server to grant only what that client requires.
Store client credentials securely, rotate them regularly, and transmit all token endpoint requests over TLS.
Validate access tokens at the resource server according to your token type, checking signature and claims for self-contained JWTs or introspecting opaque tokens, and always verify issuer, audience, and expiration.
Use short token lifetimes and have clients re-authenticate to obtain new tokens rather than relying on refresh tokens, which are typically not issued for this grant.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps