Client Credentials Grant

The client credentials grant (OAuth 2.0 RFC 6749 §4.4) lets a confidential Inbound App authenticate as itself and receive an access token with no user login or consent screen. Descope validates the client's ID and secret (or other confidential authentication), then issues a token whose scopes come from Policies on your Resources.

Use this grant for backend services, batch jobs, and autonomous agents that call your APIs or MCP servers on a fixed, admin-defined permission set.

How it works

  1. The client sends POST to the token endpoint with grant_type=client_credentials, its client_id, client authentication (typically client_secret), requested scope, and optionally resource (RFC 8707) for a specific API or MCP server.
  2. Descope verifies the client credentials and checks Policies for the app → Resource → scope combination.
  3. Descope returns an access token. There is no refresh-token rotation path tied to a user session; request a new token when the current one expires.

No consent

Client credentials tokens are governed entirely by Policies. End users never see a consent screen for this grant.

Configure in the Console

Under Grant Types:

  • Enable Client Credentials (confidential clients only).
  • Click Manage to set Allowed Tenants when the integration should be limited to specific tenants.

Ensure a Policy grants this Inbound App the scopes it needs on each Resource.

Implement

See Using Inbound Apps → Client Credentials Flow for curl and backend examples.

For cloud workload identity (AWS / GCP tokens exchanged via JWT bearer), see Using Descope with Workloads.

Was this helpful?

On this page