Topic starter
06/06/2026 11:35 am
TL;DR: Applications can create Salesforce Lead records on behalf of users without building OAuth plumbing, token storage, or refresh logic, while still relying on per-user access tokens and org-specific instance URLs, according to WorkOS. The governance issue is not convenience but the delegation model: who owns the credential, who can revoke it, and how the access path is reviewed.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Create Salesforce leads from your app without building OAuth”.
Key questions
Q: What breaks when Salesforce writes rely on delegated user tokens but no one owns the connection?
A: The main failure is governance drift.
Q: Why do per-user Salesforce connections create IAM risk even when OAuth is outsourced?
A: Because the risk moves from implementation to authority.
A: Look for evidence that the current token, the connected org, and the request destination still match the approved relationship.
Practitioner guidance
- Model Salesforce connections as governed entitlements Treat each connected org and user pair as an access relationship that needs ownership, purpose, and review.
- Track revocation as a lifecycle event Make disconnect, consent withdrawal, and org changes trigger a governance update, not just an error response.
- Review tenant routing in every SaaS write integration Verify that each write operation uses the instance URL returned for that specific org and never a hardcoded shared endpoint.
Bottom line: The core issue is not whether Salesforce records can be created efficiently, but whether the delegated access behind that action is still owned and justified.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 hours ago by NHI Mgmt Group
06/06/2026 12:29 pm
Delegated SaaS writes are an identity governance problem, not just an integration convenience. Removing OAuth plumbing lowers implementation friction, but it does not remove the need to govern who owns the connected account, who can revoke it, and how long the access remains valid. The access path still depends on per-user delegation and tenant-specific routing. Practitioners should treat this as a governed SaaS-to-SaaS access pattern, not as a low-risk API shortcut.
A few things that frame the scale:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: What is the difference between delegated access and application access in OAuth governance?
A: Delegated access acts on behalf of a signed-in user and is bounded by that user's entitlements, while application access is direct app-to-resource access with broader organisational reach. Governance must distinguish them because delegated permissions still create durable machine access paths that require lifecycle review and revocation.
👉 Read our full editorial: Creating Salesforce leads without OAuth plumbing still shifts IAM risk
This post was modified 3 hours ago by NHI Mgmt Group