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
- The client sends
POSTto the token endpoint withgrant_type=client_credentials, itsclient_id, client authentication (typicallyclient_secret), requestedscope, and optionallyresource(RFC 8707) for a specific API or MCP server. - Descope verifies the client credentials and checks Policies for the app → Resource → scope combination.
- 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.