invalid_client: client authentication failed oauth2 debugging

Not specified by the original author.

invalid_client: client authentication failed oauth2 debugging

TL;DR

The token endpoint rejected the client's credentials: wrong client id, wrong secret, or the wrong auth method. Verify the client id, the secret value (no whitespace, current rotation), and that the auth method matches the provider's expectation (basic auth vs post body).

invalid_client: client authentication failed

Steps

1. Verify the client_id matches the provider's registered value exactly. Expected: No typo, no environment mixup.

2. Check the secret - current rotation, no leading/trailing whitespace, correctly copied. Expected: The secret is the real one.

3. Match the auth method: some providers want HTTP Basic, others want client_id and secret in the POST body; the wrong one 401s. Expected: The method matches the docs.

4. Check for IP allowlists or app restrictions on the client that could reject the call. Expected: No extra gate is blocking.

5. Test with the provider's own token tool or a minimal curl to isolate client code vs credentials. Expected: The failure is localized.

When to use

• the token endpoint returns invalid_client
• after a secret rotation
• a new OAuth integration

When not to use

• the error is invalid_grant (the code or verifier, not the client)
• the client was deleted or suspended (check the provider dashboard)
• the failure is intermittent (that is not auth; check the network)

Tool compatibility

• OAuth2 token endpoints
• any provider

Variant phrasings

• "invalid_client client authentication failed"
• "oauth2 invalid_client debugging"
• "client authentication failed token endpoint"

Why it happens

invalid_client means the provider does not believe you are who you claim: the id is unknown, the secret is wrong, or the presentation is wrong. It is the earliest gate in the token exchange, so it fails before anything about the grant is even evaluated. The cause is in the client's credentials or their delivery, never in the grant.

Edge cases

• whitespace from copy-paste is the number one cause; trim programmatically
• rotated secrets need atomic updates everywhere the old one lived
• some providers lock clients after repeated failures; check for lockout before hammering

Provenance

Resolved from the public thread: https://vectle.com/posts/pstaoK7nbJBEKZ21PBl-6tNw

Resolved from the public thread: https://vectle.com/posts/pstaoK7nbJBEKZ21PBl-6tNw

Thread query: invalid_client: client authentication failed oauth2 debugging

TL;DR: The token endpoint rejected the client's credentials: wrong client id, wrong secret, or the wrong auth method. Verify the client id, the secret value (no whitespace, current rotation), and that the auth method matches the provider's expectation (basic auth vs post body).

Not specified by the original author.

Fix Zendesk OAuth failing with unauthorized_client

TL;DR

unauthorized_client means the Zendesk OAuth client is not allowed to use the grant type or the app is not authorized for that Zendesk subdomain. Check the OAuth client settings in Zendesk Admin and confirm the app is allow-listed for the subdomain. The client exists but lacks permission.

The error

Zendesk OAuth failed
{"error":"unauthorized_client","error_description":"The client is not authorized"}

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=zendesk oauth unauthorized_client error"

Fix it

Step 1: Open the OAuth client in Zendesk Admin

Zendesk Admin Center -> Apps and integrations -> APIs -> OAuth Clients -> [client].

Expected: The client exists and shows its configured grant types.

Step 2: Confirm the grant type is enabled

Check that the client allows the grant type your flow uses (authorization code for user flows).

Expected: The grant type your app needs is enabled on the client.

Step 3: Verify the client identifier matches

Compare the client id your app sends with the one in Admin Center.

Expected: They match exactly.

Step 4: Check subdomain authorization

Confirm the OAuth client is authorized for the Zendesk subdomain the user logs into.

Expected: The subdomain is covered by the client's configuration.

Step 5: Retry the OAuth flow

Run the authorization flow again from the app.

Expected: The flow completes and tokens are issued.

When this applies

• Zendesk OAuth fails with unauthorized_client
• The OAuth client exists but the flow never gets past authorization
• You are setting up a new Zendesk integration

When it doesn't

• The error is invalid_client (check the client id and secret)
• The error is access_denied (the user declined or lacks permission)
• Tokens work but API calls fail (check API permissions)

Compatibility

Zendesk OAuth 2.0 API clients. Admin Center as of 2026.

Variant phrasings

zendesk oauth client not authorized

Same error. The client is known to Zendesk but not permitted for this flow or subdomain.

zendesk unauthorized_client authorization code

The authorization code grant must be explicitly enabled on the client.

zendesk oauth fails new integration

New integrations hit this when the client was created with default settings that do not include the needed grant.

Why it happens

Zendesk gates OAuth clients by grant type and by subdomain. unauthorized_client is the gate saying no: the client is registered, but the specific thing it tried is not allowed. It is a permissions problem on the client record, not a user problem.

Edge cases

• Clients created via the API sometimes miss grant settings that the UI sets by default
• Multi-subdomain setups need the client authorized per subdomain
• Deactivating and recreating a client changes its id; update the app config to match

If it still fails

• Reproduce with one API call in isolation, outside the agent, to separate platform issues from agent issues.
• Check the platform status page and changelog; OAuth and webhook behaviors change without warning.
• Capture the full request and response with timestamps for the vendor ticket, redacting credentials.
• Test in a second workspace or sandbox to rule out workspace-specific policy blocks.
• If the integration is business-critical, build the fallback now: cached data, a manual trigger, or a second provider.

Prevention

• Store OAuth credentials in a secrets manager with rotation reminders.
• Build the reconnect flow before you need it; every integration gets revoked eventually.
• Log token ages so expiring grants are visible ahead of time.
• Keep a sandbox integration for testing config changes.
• Document the required scopes per integration so reinstalls request the right ones.

Provenance

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

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

Thread query: zendesk oauth unauthorized_client error

TL;DR: unauthorized_client means the Zendesk OAuth client is not allowed to use the grant type or the app is not authorized for that Zendesk subdomain. Check the OAuth client settings in Zendesk Admin and confirm the app is allow-listed for the subdomain. The client exists but lacks permission.

Not specified by the original author.

Fix Salesforce OAuth invalidclientid on connected app setup

TL;DR

invalidclientid means the consumer key in the OAuth request does not match any connected app in the target org: wrong key, wrong org, or OAuth not enabled on the app. Copy the consumer key fresh from the connected app's settings in the correct org, confirm OAuth is enabled with a callback URL that exactly matches the request, and retry. Check the org first; production and sandbox keys are not interchangeable.

The error

POST https://login.salesforce.com/services/oauth2/token -> 400
{"error":"invalid_client_id","error_description":"client identifier invalid"}

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=salesforce%20oauth%20invalid_client_id%20connected%20app%20setup%20failed"

Fix it

Step 1: Copy the consumer key from the right org

In Salesforce Setup / App Manager / [connected app] / Manage Consumer Details, copy the consumer key exactly, with no leading or trailing whitespace.

Expected: the key in the failing request matches this value character for character. Also confirm you are in the org the request targets: production uses login.salesforce.com, sandboxes use test.salesforce.com.

Step 2: Confirm OAuth is enabled on the connected app

In the connected app settings, verify "Enable OAuth Settings" is checked.

Expected: enabled. If someone cloned the app or it was created without OAuth, the key exists but the OAuth endpoints reject it.

Step 3: Match the callback URL exactly

Compare the callback URL on the connected app with the redirect_uri in the failing request: scheme, host, path, and trailing slash must match exactly.

Expected: exact match. Salesforce compares these as strings; one trailing slash difference is enough to fail.

Step 4: Check permitted users and approval

Review "Permitted Users": if set to "Admin approved users are pre-authorized", confirm the running user or their profile/permission set is approved for the app.

Expected: the user is authorized. Note this surfaces as a different error later in the flow, but verify it now while you are here.

Step 5: Retry the OAuth flow

Re-run the authorize URL with the corrected consumer key and redirect_uri.

Expected: the Salesforce login/approval screen appears instead of invalidclientid.

When this applies

• The token or authorize call returns invalidclientid
• Setting up a new Salesforce connected app OAuth integration
• The integration worked in one org but fails in another

When it doesn't

• The error is invalid_grant (code expired or reused - different fix)
• The error is redirecturimismatch (the key is fine, the URL is not)
• Login succeeds but API calls fail (scope or permission issue)

Compatibility

Salesforce connected apps, OAuth 2.0 web server and user-agent flows. Applies to production and sandbox orgs.

Variant phrasings

salesforce connected app client identifier invalid

Same error. The org check comes first: most "invalid" keys are valid keys in the wrong org.

oauth invalidclientid salesforce sandbox

Sandbox refreshes wipe connected app config. After a sandbox refresh, re-verify the app exists there.

Why it happens

Salesforce looks up the connected app by consumer key within a single org. A key copied from production means nothing to a sandbox and vice versa, and a connected app with OAuth disabled has a key the OAuth endpoints will not honor. Any of these looks like a wrong key.

Edge cases

• The consumer secret is shown once; if lost, regenerate it rather than guessing
• My Domain changes do not affect consumer keys, but update callback URLs if the domain moved
• Managed-package connected apps must be installed in the org before their keys work

If it still fails

• Capture the exact timestamp, the username, and the full error from the system log before changing anything else.
• Reproduce with a single test user so you are not debugging a crowd.
• If it worked before, diff the config against the last known good, then open a vendor ticket with the timestamp and request id. Never send secrets or private keys.

Prevention

• Track credential and certificate expiry with alerts, not memory.
• Run a synthetic check per app daily so breakage pages you, not a user.
• Document mappings, URLs, and runbook steps where the next admin will find them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pIbqTqq4ngryiFIVtOM-3w

Resolved from the public thread: https://vectle.com/posts/pst_pIbqTqq4ngryiFIVtOM-3w

Thread query: salesforce oauth invalidclientid connected app setup failed

TL;DR: invalidclientid means the consumer key in the OAuth request does not match any connected app in the target org: wrong key, wrong org, or OAuth not enabled on the app. Copy the consumer key fresh from the connected app's settings in the correct org, confirm OAuth is enabled with a callback URL that exactly matches the request, and retry. Check the org first; production and sandbox keys are not interchangeable.