Why does a Salesforce callback still need a run-as user in client credentials flow?

Why Salesforce still needs a run-as user in client credentials flow

Salesforce treats the callback as an action that still has to be authorized, even when no person is signing in. The token must map to a concrete security principal so the platform can evaluate object, field, and API permissions consistently. That run-as identity is what makes the integration deterministic, governable, and safe to audit.

What the run-as user is doing in the access model

In client credentials flow, the application is authenticating as itself, but Salesforce still needs a permission boundary for what that application may do after the callback arrives. The run-as user supplies that boundary. In practice, the callback inherits the account’s entitlements, which means the integration can only read or write the data that identity is already allowed to touch.

That matters because Salesforce is not granting a vague “app access” state. It is resolving a specific access context against the org’s security model, then enforcing the same kinds of checks it would use for any other authenticated principal. The result is predictable authorization instead of implicit trust in the calling app.

Why Salesforce cannot execute the callback as identity-free traffic

Without a run-as user, the platform would have no stable way to decide whose permissions apply to the access token. That would break least-privilege design and make it impossible to constrain the callback to a known profile, role, or set of API rights. A run-as user also gives administrators a concrete owner for access review, revocation, and incident investigation.

For practitioners, this is not just a technical nuisance. It is the mechanism that keeps machine-to-machine access from becoming an unbounded backdoor. If the integration later needs broader access, the correct change is to adjust the assigned identity or its permissions, not to bypass the identity layer altogether.

How this differs from a human login

A human flow brings a person, an interactive session, and usually a richer set of conditional controls. Client credentials flow does not. The platform therefore substitutes a non-interactive identity context, and the run-as user becomes the source of authorization truth for the callback. That is why the token can be valid while still being tightly scoped.

This pattern is especially important when a callback touches CRM objects, sensitive fields, or downstream APIs. The token may be service-issued, but the effective permissions are still inherited from the chosen identity, so the blast radius stays bounded by the account’s entitlements rather than the application’s intent.

Risk and Threat Considerations

A run-as user creates a clear control point, but it also becomes a high-value boundary. If that account is overprivileged, the integration can expose more Salesforce data than the business intended. If the account is weakly governed, a stolen token or abused callback can move directly through the permissions granted to that identity.

Failure mechanism: Excessive object, field, or API rights on the run-as account turn a normal client credentials callback into a broader access path, especially when the integration is reused across multiple workflows or orgs.

Impact: Attackers or misconfigured automations can read, modify, or export CRM data beyond the intended scope, and defenders may struggle to distinguish legitimate machine activity from abuse if the account is shared or poorly monitored.

Practitioner Guidance

What to verify: Confirm that the selected run-as user has only the object, field, and API permissions the callback actually needs. If the account can reach more records or APIs than the integration uses, treat that as a design flaw rather than an acceptable convenience.

Common mistake: Using a powerful admin-style account because it “makes the callback work” faster. That approach usually creates unnecessary exposure and makes later audit or rotation work harder than it should be.

Decision rule: If the callback can succeed with a narrower identity, use the narrower one. If you need to expand access, do it by changing the governing identity and reviewing the downstream permissions, not by weakening the client credentials pattern itself.

Practitioner takeaway: The run-as user is not an implementation detail, it is the authorization boundary that keeps Salesforce machine access accountable, reviewable, and limited to the permissions you are prepared to defend.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• How can organizations secure their MCP server credentials?
• How should security teams implement Client ID Metadata Documents?
• When should organizations transition from static to dynamic credentials?