Topic starter
12/06/2026 9:17 pm
TL;DR: Salesforce OAuth 2.0 client credentials flow can replace refresh-token handling for server-to-server callback notifications, but only when the app, scope, and run-as user are configured correctly, according to OneSpan. The governance question is not token convenience, but how tightly integration identity, permission scope, and callback trust are controlled.
Editorial analysis by NHI Mgmt Group, based on content published by OneSpan: “OneSpan Sign – Salesforce OAuth 2.0 Client Credentials Flow”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Salesforce client credentials flow simplifies server-to-server callback handling, but it does not remove the need for governed identity, scope, and secret handling.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/06/2026 11:15 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Salesforce client credentials flow changes callback governance