Notifications
Clear all
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.
NHIMG editorial — based on content published by OneSpan: Salesforce OAuth 2.0 client credentials flow for OneSpan Sign developers
Questions worth separating out
Q: How should teams govern Salesforce client credentials flows for server-to-server callbacks?
A: Treat the callback as a non-human identity with an assigned owner, a scoped app, and a defined run-as user.
Q: Why do Salesforce callbacks fail when the run-as user is not set correctly?
A: The client credentials flow needs a user context to determine what the issued token can do.
Q: What do security teams get wrong about client credentials flow scopes?
A: They often keep refresh_token or offline_access in the app configuration out of habit from delegated flows.
Practitioner guidance
- Map the callback to a governed NHI owner Assign ownership for the Salesforce callback integration to a named platform or identity team, and treat the client_id, client_secret, and run-as user as one managed identity set.
- Separate client credentials flows from delegated OAuth patterns Remove refresh_token and offline_access from any app used for server-to-server callbacks, and verify that only api scope is granted.
- Validate the callback endpoint before registration Confirm the Apex REST resource exists, the namespace path is correct, and the callback URL matches the org host exactly before registering the listener.
What's in the full article
OneSpan's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Salesforce setup paths for both Connected Apps and External Client Apps
- The exact Apex REST callback class example and endpoint validation checks
- Base64 encoding commands and troubleshooting notes for Linux and macOS
- The comparison table that contrasts client credentials flow with refresh token flow
👉 Read OneSpan's guide to Salesforce OAuth 2.0 client credentials callbacks →
Salesforce client credentials flow for callbacks: what changes?
Explore further
12/06/2026 11:15 pm
Client credentials callback identity is a non-human identity governance problem, not a token-format choice: The article is really about which identity boundary governs a server-to-server callback, and that is an NHI boundary. The access decision shifts from user consent to application and run-as-user control, which means identity, scope, and callback trust have to be managed together. Practitioners should treat the integration as a governed machine identity rather than a convenience shortcut.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: How do teams know if a Salesforce callback integration is configured safely?
A: They should verify three things: the app is explicitly enabled for client credentials flow, the callback endpoint resolves in the target org, and the encoded key contains the correct host and secret values. If any of those drift, the integration may still exist technically but will not be trustworthy operationally.
👉 Read our full editorial: Salesforce client credentials flow changes callback governance
