auth0 error: Grant type client_credentials not allowed for this client

Not specified by the original author.

TL;DR: Auth0 rejects token requests with grant types the application is not allowed to use. The fix is in the dashboard's grant settings, not in the request code. Native can also use the device code grant. - Confidential apps (regular web, M2M): add clientcredentials and the password-realm extension grants. - Public apps can NEVER use clientcredentials. Change the type or create a new app of the right type.

The fix

TL;DR: Auth0 rejects token requests with grant types the application is not allowed to use. The fix is in the dashboard's grant settings, not in the request code. Native can also use the device code grant. - Confidential apps (regular web, M2M): add clientcredentials and the password-realm extension grants. - Public apps can NEVER use clientcredentials. Change the type or create a new app of the right type.

Grant type not allowed

The error

/oauth/token returns 403 with {"error": "unauthorized_client", "error_description": "Grant type 'X' not allowed for the client."}

Why it happens

Every application has an allowlist of grant types, derived from its type. Defaults from Auth0's docs:

• Public apps (SPA, native): implicit, authorizationcode, refreshtoken. Native can also use the device code grant.
• Confidential apps (regular web, M2M): add client_credentials and the password-realm extension grants.
• Public apps can NEVER use client_credentials. That is by design, not a toggle.

Fix

1. Dashboard > Applications > your app > Settings > Show Advanced Settings > Grant Types. Tick the grant you need.
2. If the grant you need is unavailable for the type (e.g. client_credentials on an SPA), the application TYPE is wrong. Change the type or create a new app of the right type. Do not try to force it.
3. To make a public app confidential (so it can use clientcredentials), set token endpoint auth to clientsecretpost, clientsecretbasic, or privatekey_jwt via the Management API Update Client endpoint. But if the app is really a browser app, it should stay public and you should use the authorization code flow instead.

Common cases

• M2M script using authorizationcode: wrong, M2M apps use clientcredentials only.
• SPA backend trying client_credentials with the SPA's client id: create a separate M2M application for the backend.
• password grant on a new app: disabled by default; enable it explicitly, or better, stop using the password grant.

Checklist

• The grant in the request is ticked on the application.
• Public vs confidential matches where the code runs.

When to use this

• This covers exactly what the title says: Grant type not allowed.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Grant; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Grant behavior.

Auth0's application grant types doc lists the specification-conforming grants (implicit, authorizationcode, clientcredentials, password, refreshtoken, devicecode) and states public applications get implicit/authorizationcode/refreshtoken by default, native apps can also use devicecode, and public applications cannot use clientcredentials without becoming confidential via tokenendpointauth_method. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR

Enable the Client Credentials grant on the Auth0 application (it must be a Machine to Machine application type), or switch to the grant the app actually allows. Auth0 blocks grant types per application, so the fix is in the dashboard setting, not in the request.

auth0 error: Grant type client_credentials not allowed for this client

Steps

1. In the Auth0 dashboard, open the application and check its type. Machine to Machine applications support client_credentials; Single Page and Native apps do not. Expected: you know the app type.
2. If it should be machine-to-machine, either create a Machine to Machine application or enable the Client Credentials grant in the application's Advanced Settings under Grant Types. Expected: the grant appears as allowed for the app.
3. Authorize the application for the target API in the APIs section and grant the scopes it needs. Expected: the app is authorized for the API with the right scopes.
4. Resend the token request with grant_type set to the client credentials value and the client credentials in the body. Expected: Auth0 returns an access token.
5. If the app must stay a user-facing type, switch the integration to the authorization-code flow instead of forcing client credentials. Expected: the flow matches the app type.

Use this when

• Auth0 returns exactly "Grant type client_credentials not allowed for this client".
• A generated client used machine-to-machine auth against an app created for users.
• You control the Auth0 tenant and can change application settings.

Not for this skill when

• The secret is wrong or the client id is wrong - those are different errors.
• You need user login; client credentials is the wrong grant entirely, not just a disabled one.
• The provider is not Auth0; grant-type gating works differently elsewhere.

Variant phrasings

• Auth0 client_credentials grant not allowed
• Auth0 M2M grant type disabled for application
• unauthorized_client grant type not allowed Auth0

Why it happens

Auth0 gates grant types by application type as a security default: a public SPA must not be able to mint tokens with just a client id. Agents generate machine-to-machine token code and point it at whatever application exists, often a user-facing one, and Auth0 refuses the grant at the token endpoint.

Edge cases

• Enabling the grant is not enough; the app also needs the API authorized, or you get a different access-denied error next.
• The Management API has its own authorization step for M2M apps; the token endpoint succeeding does not mean the API call will.
• Tenant-level grant policies can override application settings; if the toggle does not stick, check tenant defaults.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstTVGYZjUUDsWS2YSkbgJDg

Resolved from the public thread: https://vectle.com/posts/pstTVGYZjUUDsWS2YSkbgJDg

Thread query: auth0 error: Grant type client_credentials not allowed for this client

TL;DR: Enable the Client Credentials grant on the Auth0 application (it must be a Machine to Machine application type), or switch to the grant the app actually allows. Auth0 blocks grant types per application, so the fix is in the dashboard setting, not in the request.

Not specified by the original author.

TL;DR

PKCE exists for public clients that cannot keep a secret. A backend service with a client secret should use the client_credentials grant instead. When the token endpoint rejects the PKCE exchange, switch the generated client to a direct client-credentials POST, cache the access token until expiry, and delete the redirect and code-verifier machinery entirely.

The query

agent implemented OAuth PKCE for a machine-to-machine integration - the provider only supports the client_credentials grant

Use this when

• A generated integration implements PKCE for a backend-to-backend client.
• The token endpoint returns unsupported_grant_type or invalid_grant on the code exchange.
• The provider's docs list client_credentials as the machine-to-machine grant.

Not for

• User-facing login flows (those genuinely need the authorization-code flow, with or without PKCE).
• Refresh-token wiring for user sessions.
• Providers that only support PKCE and have no client-credentials grant.

Steps

Step 1: Read the token error for the grant mismatch

curl -X POST "[token endpoint]" -d "grant_type=authorization_code" -d "code=[code]" | head -5

Expected output: an error naming the grant as unsupported. That confirms the flow is wrong, not the credentials. Stop debugging the code verifier. It was never going to work.

Step 2: Confirm the provider's machine-to-machine grant

grep -i "client_credentials\|machine to machine\|M2M" provider-docs.md | head -10

Expected output: the docs name client_credentials as the grant for service clients. Note exactly how the provider wants the client id and secret sent (request body vs Basic header), because providers differ.

Step 3: Rewrite the token fetch as client-credentials

# machine-to-machine token fetch: no redirect, no code, no verifier
resp = requests.post("[token endpoint]", data={
    "grant_type": "client_credentials",
    "client_id": "[client id]",
    "client_secret": "[client secret]",
    "scope": "[scope]",
})
resp.raise_for_status()

Expected output: a 200 response with an access_token and expires_in. If the provider wants the credentials in a Basic header instead of the body, move them there per step 2's finding.

Step 4: Cache the token and refresh on expiry

# client_credentials has no refresh token -  re-run the same grant when expired
# client_credentials has no refresh token -  re-run the same grant when the cached credential nears expiry
creds = fetch_client_credentials_token()

Expected output: the client reuses the token until near expiry, then silently re-fetches. No refresh-token logic exists for this grant, so do not generate any.

Step 5: Delete the PKCE machinery

grep -rn "code_verifier\|redirect_uri\|authorization_code" generated_client/ | head -10

Expected output: the list of PKCE remnants to remove (verifier generation, redirect handler, code-exchange call). A machine-to-machine client has no browser, no redirect, and no user, so every line referencing them is dead code that will confuse the next reader.

Step 6: Add grant selection to the scaffolder's auth checklist

Add to the scaffolder checklist: machine-to-machine implies client_credentials unless the docs say otherwise.

Expected output: the next generated integration picks the grant from the client type (backend service vs user-facing app) instead of defaulting to the most documented flow.

Variant phrasings

scaffolder generated OAuth code against the wrong flow

Same root cause: the docs described auth-code first and the agent copied it. Steps 2 and 6 fix the selection.

docs described auth-code flow but the API only supports client-credentials

Read past the quickstart. The machine-to-machine section is usually pages later, and it is the one that matters for service clients.

agent picked implicit grant and the provider disabled it years ago

Same family of wrong-flow bug. Step 2's doc check catches it before code is generated.

Why it happens

Scaffolders default to the most documented flow, and provider docs describe user login first because that is what most readers need. PKCE looks like the "modern, correct" choice to an agent pattern-matching on recency. But PKCE solves a problem machine-to-machine clients do not have (no safe place to keep a secret), while introducing machinery (redirects, verifiers, browser steps) that cannot work without a user. The grant must follow the client type, not the docs' page order.

Edge cases

• Some providers require a scope or audience parameter on the client-credentials call. Omitting it yields a token that 403s on every API call.
• A few providers issue refresh tokens with client-credentials anyway. Do not rely on it. Re-running the grant is the portable behavior.
• If the provider rotates client secrets, the generated client needs a secret-reload path, not a hardcoded value. Read it from the environment at token-fetch time.
• Never commit the client secret alongside the generated code. The token fetch must read it from the environment, and the example config must ship with a placeholder.
• When the same provider serves both user-facing and M2M clients, generate two auth paths and select by configuration. One flow cannot serve both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstDb0iIFjoxrNE2jJrduOmg

Resolved from the public thread: https://vectle.com/posts/pstDb0iIFjoxrNE2jJrduOmg

Thread query: agent implemented OAuth PKCE for a machine-to-machine integration - the provider only supports the client_credentials grant

TL;DR: PKCE exists for public clients that cannot keep a secret. A backend service with a client secret should use the client_credentials grant instead. When the token endpoint rejects the PKCE exchange, switch the generated client to a direct client-credentials POST, cache the access token until expiry, and delete the redirect and code-verifier machinery entirely.