The flow fails because refresh_token and offline_access belong to user-delegated OAuth patterns, not client credentials flow. In this setup, Salesforce expects the api scope and a valid run-as user context. If the scopes are wrong, the callback cannot authenticate cleanly and the integration returns invalid_grant rather than falling back safely.
Why the Salesforce client credentials flow breaks when scopes are wrong
In Salesforce, the client credentials flow is not a generic “any OAuth scope works” path. It is a tightly defined machine-to-machine exchange, so the requested scopes have to match the grant type and the connected app configuration. When the scope set is borrowed from a delegated-user pattern, the token request can fail before the integration ever reaches the API call.
The practical consequence is that the failure is usually deterministic, not graceful. Instead of silently substituting a nearby permission set, Salesforce rejects the exchange with invalid_grant, because the requested authorization context does not line up with the flow the platform expects.
Why api differs from refresh_token and offline_access in this flow
The core mismatch is between delegated OAuth patterns and client credentials. RFC 6749: The OAuth 2.0 Authorization Framework defines the client credentials grant as a non-user flow, so scopes that imply a user session or refreshable delegated consent do not belong there. In Salesforce, that matters because the platform expects the API scope plus the right run-as context, not a user-delegated token lifecycle.
That is why refresh_token and offline_access can be valid in other OAuth patterns but become a configuration error here. They signal a token model built around user authorization and renewal, while client credentials is meant to obtain direct application access for a specific API audience.
What the failure tells you about Salesforce authorization
A wrong-scope failure is usually pointing to a deeper mismatch in how the connected app, integration user, and token audience are set up. The integration is not just “missing a permission”; it is asking Salesforce to mint a token under rules that do not fit the grant. If the run-as user is missing, the app is mis-scoped, or the connected app expects a different OAuth pattern, the callback cannot complete cleanly.
For implementation detail and flow selection, OAuth 2.0 and OpenID Connect Guide for Identity Teams is the right internal reference for separating client credentials from delegated OAuth patterns, and API Key Management Guide is useful when the integration has to be reworked around clearer credential scoping and lifecycle choices.
Risk and Threat Considerations
Wrong OAuth scopes do more than cause a setup error. They can hide a design problem where teams think they have a machine-to-machine integration, but the configuration still depends on user-style consent or long-lived access assumptions. That creates operational fragility, and in some environments it also encourages insecure workarounds such as overbroad scopes or shared accounts.
Failure mechanism: The client credentials exchange fails because the requested scopes do not match the grant type, so Salesforce cannot issue a valid access token for the intended API context.
Impact: The integration returns invalid_grant, scheduled jobs or automated syncs stop working, and teams may be tempted to widen scopes or misuse delegated tokens to restore service.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Wrong scopes break OAuth token issuance for the API integration. |
| Recommendation — Validate token flows and scope settings so the API can authenticate under the intended grant. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Salesforce client credentials is a non-user integration authentication pattern. |
| IA-5 — Authenticator Management | Scope and token handling depend on proper credential and token lifecycle control. | |
| Recommendation — Align machine authentication with the correct grant and credential context. Restrict, rotate, and validate authenticators used by the integration. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | OAuth scopes and token handling are authentication information that must be protected and correctly used. |
| Recommendation — Manage authentication information so only the right OAuth pattern can obtain access. | ||
| OWASP ASVS | V10 — OAuth and OIDC | The issue is a misconfigured OAuth grant and scope set. |
| Recommendation — Verify the OAuth grant type and scope mapping for the integration flow. | ||
Practitioner Guidance
What to verify: Confirm that the connected app is configured for the client credentials flow, that the scope set is limited to what the API call actually needs, and that a valid run-as user exists where Salesforce requires one. If the requested scopes include refresh_token or offline_access, treat that as a sign you are mixing grant models.
Decision rule: If the integration is service-to-service, keep the token model machine-oriented and audit the scope set against the exact API operation. If the use case needs user delegation, switch the design instead of trying to force client credentials to behave like an interactive OAuth flow.
Practitioner takeaway: Scope errors in OAuth are often architecture errors in disguise, so fix the grant model and authorization context first, then the token request will usually fall into place.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org