Standing OAuth access turns a third-party integration into a persistent trust bridge. If that app is compromised, stolen, or over-permissioned, attackers can reuse delegated access to read, sync, or export sensitive records without stealing a user password. The failure is usually lifecycle control, not authentication alone, because the grant stays active long after the business need has changed.
Why This Matters for Security Teams
Standing OAuth access is not just an application convenience issue. It creates a durable authorization path that can outlive the person, vendor, workflow, or business purpose that justified it. Once a Salesforce integration has persistent access, the real risk shifts from login security to delegated privilege, token exposure, and weak revocation discipline. That is why the control problem maps closely to lifecycle governance and non-human identity oversight, as reflected in the OWASP Non-Human Identity Top 10.
Security teams often miss that OAuth consent is effectively an ongoing trust decision, not a one-time setup step. If scopes are broad, refresh tokens are long-lived, and ownership is unclear, the integration can keep working even after the business case has ended. That makes discovery, review, and revocation just as important as initial approval. In environments with sales ops automation, reporting pipelines, or customer data syncs, stale grants can quietly expand the blast radius of a compromise.
In practice, many security teams encounter unauthorized data movement only after a trusted integration has already been abused, rather than through intentional lifecycle review.
How It Works in Practice
OAuth integrations with Salesforce typically rely on a mix of access tokens and refresh tokens. Short-lived access tokens reduce immediate exposure, but standing access usually persists because the refresh token can mint new sessions until it is revoked, rotated, or invalidated by policy. That means the key questions are who approved the grant, what scopes were granted, where the token is stored, and what conditions trigger removal.
A practical control model should treat the integration as a non-human identity with an owner, purpose, expiry expectation, and review cadence. Security and platform teams should inventory connected apps, map them to data access, and verify whether the integration needs read-only access, write access, export capability, or administrative scope. The NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful anchor for access enforcement, account management, and auditability.
- Identify every connected app and the business owner responsible for it.
- Review OAuth scopes against the minimum data and actions required.
- Separate production, sandbox, and vendor test access so grants do not spread.
- Set expiry or periodic reauthorization for integrations that are not permanently justified.
- Revoke refresh tokens when vendors change, contracts end, or use cases disappear.
- Log token issuance, API use, and anomalous data retrieval for detection and response.
Where possible, use stronger trust patterns such as certificate-based authentication, workload identity federation, or tightly scoped service accounts instead of broad user-delegated grants. Current guidance suggests that standing OAuth should be limited to integrations with a clearly documented operational need, because continuous authorization is harder to justify than time-bound access. These controls tend to break down in large Salesforce estates with many business-unit-owned apps because ownership becomes fragmented and revocation decisions are delayed.
Common Variations and Edge Cases
Tighter OAuth governance often increases operational overhead, requiring organisations to balance integration uptime against the cost of periodic review and reauthorization. That tradeoff becomes sharper when Salesforce powers revenue workflows, partner portals, or customer support automations that cannot tolerate frequent interruption.
There is no universal standard for how often standing access should be revalidated, but best practice is evolving toward risk-based review intervals rather than blanket annual checks. High-volume integrations that move regulated or customer-sensitive data deserve shorter review cycles, while low-risk internal automations may justify longer ones if scope is tightly constrained. The key is to avoid treating all connected apps as equal.
Edge cases also matter. Some integrations are technically “standing” because the workflow must run continuously, yet the real control objective is not elimination but containment. In those cases, use narrow scopes, separate credentials per environment, and strong monitoring of token use. If the integration is provided by a third party, contract language should support immediate revocation, security notification, and proof of access removal when the relationship ends. The OWASP Non-Human Identity Top 10 is especially useful here because it treats these grants as identities that need governance, not just technical configuration.
Standing OAuth becomes most dangerous when the integration is forgotten, the business owner changes, and the original consent is still silently valid.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | Standing OAuth grants are non-human identities that need lifecycle governance. | |
| NIST CSF 2.0 | PR.AA-01 | OAuth access should be governed as an access control and asset management issue. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management controls support timely creation, review, and removal of integration access. |
Inventory each connected app as an identity and enforce owner, purpose, expiry, and revocation controls.
Related resources from NHI Mgmt Group
- What breaks when organisations keep standing privilege for high-risk admin access?
- What breaks when Salesforce integrations rely on broad service account access?
- What breaks when service accounts keep long-lived standing access?
- What breaks when collaboration platforms keep standing access for contractors and suppliers?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
