Salesforce client credentials flow changes callback governance

At a glance

What this is: This is a configuration guide for using Salesforce OAuth 2.0 client credentials flow for OneSpan Sign callbacks, with the key finding that server-to-server setups still depend on tightly governed app settings, scopes, and run-as user context.

Why it matters: It matters because callback integrations can look simpler while still creating permission and trust risks if identity scope, token handling, and execution context are not governed as part of the integration lifecycle.

Context

Salesforce client credentials flow is a server-to-server OAuth pattern used when no human user needs to approve the interaction. In this setup, the integration still depends on a defined application, a scoped token request, and a Salesforce context that can execute the callback safely.

The operational gap is not whether the callback can authenticate, but whether the integration identity is constrained enough to avoid overreach. For NHI governance, the important question is how callback access is issued, scoped, and tied to the right run-as account across the app lifecycle.

Key questions

Q: What breaks when Salesforce client credentials flow is configured with the wrong scopes?

A: 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.

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

A: Because Salesforce has no interactive user in the flow, it needs a real identity context to apply permissions to the access token. The run-as user becomes the authority boundary for the callback, which means object, field, and API permissions are inherited from that account. Without it, the integration cannot execute with defined access.

Q: How can security teams tell whether a server-to-server callback is overprivileged?

A: Look for a callback account that has broader object, field, or admin permissions than the event-processing logic requires. If the integration can reach records or APIs that are unrelated to signing events, the run-as user is too wide. The goal is to keep callback authority narrow enough that a compromised secret cannot move beyond its intended function.

Q: What is the difference between refresh-token flow and client credentials flow for callbacks?

A: Refresh-token flow depends on an initial user authorization and ongoing token rotation, while client credentials flow authenticates the app directly and uses a run-as user for permission context. For server-to-server callbacks, the latter removes user interaction but increases the importance of app registration, secret custody, and scope hygiene.

Technical breakdown

Client credentials flow for Salesforce callbacks

Client credentials flow replaces user-delegated token exchange with an application authenticating directly to Salesforce. For callback notifications, that means the consuming service presents its client_id and client_secret instead of a refresh token, and Salesforce issues access in the context of the configured run-as user. This removes interactive consent and refresh-token rotation, but it does not remove the need for authorization design. The app still needs the right OAuth scopes, and the token still inherits the privileges of the selected identity. If the app or run-as user is too broad, the callback channel becomes an overprivileged integration path rather than a controlled machine identity.

Practical implication: Treat the callback app as a governed NHI, not as a convenience shortcut.

Run-as user and permission inheritance

Salesforce requires a run-as user because client credentials flow has no interactive person behind the token. That user becomes the authority boundary for the callback, which means the callback can only do what that identity can do. If the user is inactive, lacks API Enabled, or is missing object and field permissions, Salesforce returns errors such as invalid_grant. If the user is broader than necessary, the integration inherits excess privilege. In governance terms, the run-as selection is the control point where machine access becomes accountable, auditable, and bounded to a specific operational role.

Practical implication: Review run-as users as privileged non-human identities with explicit ownership and scope.

OAuth scope hygiene and callback trust

The article makes clear that refresh_token and offline_access do not belong in this flow. Those scopes belong to user-delegated patterns and will break the client credentials setup, while the api scope is the one that supports server-to-server callback access. The base64-encoded key also binds host, client_id, and client_secret into a single credential blob, so mistakes in encoding or host selection become authentication failures or misdirected trust. This is a classic identity hygiene issue: the integration only works when the callback trust chain is narrow, correctly encoded, and aligned to the right Salesforce domain.

Practical implication: Validate scopes, host values, and secret packaging as part of callback onboarding.

NHI Mgmt Group analysis

Callback integrations are NHI governance problems, not just OAuth plumbing. Salesforce client credentials flow shifts the security question from user consent to machine identity control. The callback still needs an identity, a scope boundary, and a lifecycle owner, which makes it a non-human identity pattern rather than a pure application setting. Practitioners should treat the integration as an access path with its own governance record, not as an incidental transport detail.

Run-as selection is the decisive control boundary in this pattern. Salesforce uses the run-as user to define the permissions available to the callback, which means the integration inherits the authority of that account. That makes the account itself part of the machine identity estate, with the same risks as any privileged service account. The practical conclusion is that callback permissions should be designed around the minimum object and field access needed for event handling.

Client credentials flow reduces token handling, but it does not eliminate trust assumptions. The article removes refresh-token rotation from the setup, yet the integration still depends on a static secret, a correctly scoped app, and a valid Salesforce domain. That is a useful simplification for server-to-server integrations, but it also concentrates control into fewer credentials. The implication is that callback governance moves upstream to app registration, scope design, and secret custody.

Identity blast radius is the right concept for callback architecture. OneSpan's setup shows how a single callback identity can touch events, documents, and Salesforce records through one run-as context. That creates a compact but high-impact access path, so the question is not whether the flow works, but how much damage a mis-scoped callback could do. Practitioners should design for the smallest possible blast radius from the outset.

Secrets management and OAuth scope governance have to be aligned in the same control plane. The base64-encoded key combines host, client_id, and client_secret, so secret handling errors become authentication failures or trust failures immediately. This makes callback onboarding a lifecycle issue, not a one-time configuration step. The takeaway for identity teams is to govern the secret, the app, and the run-as identity together.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Callback identity should be governed like any other machine identity. A Salesforce integration that posts signing events is not a temporary script. It is a persistent non-human identity with a secret, a scope boundary, and a privilege model that should be reviewed like any other service account. Teams that do not inventory callback identities will miss where trust is actually granted.

Secrets sprawl is the hidden failure mode in OAuth callback design. The same integration may include a client_secret, a host value, and a run-as user, which means one weak control can undermine the whole trust chain. When credentials are bundled for convenience, ownership and rotation discipline usually lag behind deployment speed.

OAuth callback trust should be measured at issuance time, not after incidents. If the app registration, scope set, and run-as account are not verified together, the callback can authenticate with the wrong authority even when it technically works. That makes onboarding checks more important than post-deployment troubleshooting.

For practitioners

• Define the callback as a governed non-human identity Create an ownership record for the Salesforce callback app, its secret material, and the run-as user so the integration has a lifecycle owner and review path.
• Scope the run-as user to the smallest viable permissions Use an active integration or admin user only when needed, then strip the account down to API Enabled plus the exact object and field permissions required by the callback.
• Remove user-delegated OAuth scopes from the flow Exclude refresh_token and offline_access from the app configuration and use api only, because those user-delegated scopes will break client credentials flow.
• Treat the encoded key as a sensitive integration secret Protect the base64-encoded host, client_id, and client_secret bundle as a credential, and validate the Salesforce host value before deployment to avoid invalid_grant failures.
• Test callback identity before production cutover Verify the Apex REST endpoint, callback registration, and OAuth configuration in a non-production org before enabling event traffic in the live Salesforce environment.

Key takeaways

• Salesforce client credentials flow simplifies server-to-server callback handling, but it does not remove the need for governed identity, scope, and secret handling.
• The run-as user is the decisive permission boundary, because the callback inherits that account's access rather than acting as an unowned integration.
• Callback security depends on correct OAuth hygiene, especially scope selection, host validation, and secret packaging.

Key terms

• Client Credentials Flow: An OAuth 2.0 grant type used for machine-to-machine authentication where an application authenticates directly using its own client ID and secret to obtain an access token. The standard pattern for service-to-service NHI authentication.
• Run-as User: The Salesforce user context that supplies the effective permissions for a client credentials flow. It is the privilege anchor for the integration, which means its status, permissions, and lifecycle must be managed like a privileged non-human identity.
• Callback Identity: The non-human identity used to receive and process event notifications from another system. In practice, it combines an OAuth client, a secret, and a permission context, so it must be governed like any other machine or service account rather than treated as a simple webhook.
• Secret Packaging: The way credentials and related metadata are bundled for transport or registration, such as host, client_id, and client_secret in one encoded object. Poor packaging does not just affect convenience, it can also create authentication failures, secret sprawl, and misplaced trust in the receiving system.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.