The governance boundary breaks first. A malicious OAuth grant can look like normal business authorisation while actually creating durable access into CRM data, downstream APIs, and other cloud services. That is why connected-app approvals need the same scrutiny as privileged account changes, not the same treatment as ordinary productivity consent.
Where approval without review turns a consent flow into an access-control failure
When users can approve Salesforce connected apps on their own, the control stops behaving like governance and starts behaving like delegation with very weak oversight. A consent click can create standing access, token issuance, or cross-cloud trust that outlives the moment of approval, so the real question is who is allowed to create durable integration paths, not who can click “allow.”
That is why connected-app approval belongs in the same control family as access request, entitlement change, and privileged integration setup. When the approval process is loose, the environment can accumulate hidden trust relationships that are hard to inventory, harder to review, and easy to misuse later.
For practitioners, the important distinction is between convenience consent and governed authorisation. If the app can read CRM records, offline tokens, or downstream SaaS data, the approval is not a lightweight productivity action, it is a security decision that changes blast radius.
Why malicious OAuth grants are so effective
Malicious connected apps work because they can appear routine while granting durable access behind the scenes. Once a user or admin approves the integration, the app may receive scopes, refresh capability, and a trust relationship that bypasses many of the normal signals defenders use for interactive logins.
In practice, that makes the approval path attractive to attackers who want low-friction persistence. They do not need to defeat the password policy if they can persuade a user to authorise an app that is already trusted by the platform and by adjacent business workflows.
Because Salesforce is often connected to ticketing, marketing, support, and data export tooling, one bad grant can become a lateral movement path across SaaS environments. That is why ShinyHunters Salesforce data theft campaign 2025 and Salesloft OAuth token breach are useful reminders that the approval event itself can be the point where durable access is created.
What governance has to catch before the grant becomes normalised
Once user approval is allowed, the failure mode is not only unauthorised access, it is normalisation. Repeated approvals teach the organisation to treat third-party access as routine, which makes it harder to spot unusual scopes, third-party risk, and exceptions that should have required review.
That is why teams need explicit ownership for connected-app governance, not just IAM configuration. The review should ask whether the app is approved for the business function, whether its scopes are proportionate, whether the token lifetime is bounded, and whether the vendor relationship is understood well enough to survive compromise.
A practical control point is access certification. If app approvals are never revisited, the environment will keep stale integrations long after the original business need has expired. A governed review process, such as Access Reviews and Certification Guide, helps teams treat these approvals as revocable entitlements rather than permanent convenience.
The broader operating model also matters. IAM and IGA Basics is the better lens when you need to decide who may approve, under what policy, and how those approvals are recertified.
Risk and Threat Considerations
Unreviewed connected-app approval creates a high-value abuse path because it combines user trust, OAuth delegation, and SaaS-to-SaaS connectivity. The risk is not limited to one Salesforce tenant, because the resulting token or grant may expose CRM data, downstream APIs, and other cloud services that trust the same integration chain.
Failure mechanism: An attacker persuades a user or over-permissioned approver to authorise a malicious or compromised app, then uses the issued grant or token to read data, export records, or pivot into connected services without needing another interactive login.
Impact: Organisations can lose confidentiality, create persistent access paths that survive password resets, and miss the compromise because the activity looks like normal business authorisation rather than a malicious login event.
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 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Unreviewed app approvals create durable grants that must be revoked when no longer needed. |
| NHI-02 — Secret Leakage | OAuth tokens and app grants can expose sensitive access material if approval is mishandled. | |
| NHI-05 — Overprivileged NHI | Connected apps often receive scopes beyond what the business function needs. | |
| Recommendation — Revoke unused connected-app grants promptly and remove stale OAuth access paths. Protect and rotate tokens tied to connected apps before they expose data. Restrict connected-app scopes to least privilege and deny broad data access by default. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Approved apps may bypass normal login checks through delegated OAuth access. |
| API5 — Broken Function Level Authorization | App approvals can expose privileged CRM actions if scopes are too broad. | |
| Recommendation — Validate delegated authentication flows and reject weak token-based trust. Verify each app scope blocks unauthorized functions and sensitive CRM operations. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Connected-app approvals should limit the permissions granted to each integration. |
| IA-5 — Authenticator Management | OAuth tokens and secrets used by apps need lifecycle control after approval. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Approval events and token use need review to spot suspicious consent and misuse. | |
| Recommendation — Apply least privilege to app approvals and remove excess scopes. Rotate and expire app credentials and tokens on a defined schedule. Review connected-app approvals and token activity for anomalies. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Connected-app approvals are an access-control decision over SaaS data and functions. |
| A.8.3 — Information access restriction | App scopes must be restricted to the minimum data and actions needed. | |
| Recommendation — Define who may approve apps and require controls before access is granted. Limit app scopes to the smallest set of required records and actions. | ||
Practitioner Guidance
What to prioritise: Treat connected-app approval as an entitlement change, not a convenience setting. The highest-risk cases are apps with offline access, broad data scopes, export capability, or any path into production CRM records.
What to verify: Confirm who can approve apps, whether approvals are admin-only for sensitive scopes, and whether every approved app has an owner, a business purpose, and a defined review date. If you cannot name those three things, the grant is already too loose.
Decision rule: If the app can obtain persistent tokens or touch customer data, require pre-approval and periodic recertification. If it only supports low-risk productivity functions, still constrain scopes and monitor for scope creep rather than assuming user consent is harmless.
Practitioner takeaway: The governance boundary is the control that breaks first, so the objective is to make every connected-app approval revocable, reviewable, and proportionate to the data it can reach.
Related resources from NHI Mgmt Group
- What breaks when AI-generated mobile apps are shipped without security review?
- What breaks when employees can connect SaaS apps without security review?
- What breaks when downstream apps let users add a new SSO method without re-verification?
- What breaks when Salesforce connected apps share one integration user?