Salesforce Connected App is an application integration object that lets an external app authenticate to Salesforce and request scoped access. It defines OAuth settings, permitted scopes, and often policies such as single sign-on, certificate use, or IP restrictions for API access.
What a Salesforce Connected App actually does
A Salesforce connected app is the control point that lets an external application request access to Salesforce through OAuth. It is where the integration is defined, approved, and constrained, so the app can authenticate and receive only the scopes and policies the org allows.
Because the connected app sits at the trust boundary between Salesforce and an outside system, it is more than a registration record. It determines whether an app can sign in at all, what API actions it can perform, and whether additional restrictions such as certificate use, IP rules, or approval workflows are enforced.
Why connected app design matters for access control
Connected apps turn a SaaS integration into a governed access path. The practical security question is not just whether the app works, but whether its scopes, token lifetime, and permitted users match the business need with minimal exposure. NHIMG’s Salesforce Security Guide places connected apps alongside permission sets, profiles, guest access, and monitoring because they are part of the same access-control surface.
That matters because OAuth grants are durable unless intentionally constrained or revoked. A connected app can create long-lived access to CRM data, automation capabilities, and API-driven exports, which makes scope design and approval policy part of the security model, not just implementation detail.
Connected apps in the SaaS integration lifecycle
Connected apps are usually created for a specific integration, but they often outlive the original project, owner, or vendor relationship. Over time, stale grants, unused scopes, and forgotten certificates can accumulate, especially when teams install many apps for sales, support, analytics, or migration work.
That lifecycle issue is why inventory and periodic review matter. A connected app should be discoverable, tied to an owner, and re-evaluated when the integration changes. If the app still needs access, its scopes should remain narrow; if it no longer does, the grant should be removed rather than left dormant.
Authentication, scopes, and trust boundaries
Salesforce connected apps are typically governed through OAuth settings, which makes the connected app the policy layer for how an external system authenticates. The app may also define which users or profiles can authorize it, whether refresh tokens are allowed, and whether authentication depends on certificates or network restrictions.
That combination of settings creates a trust boundary that should be treated like any other privileged integration. The more permissive the scopes and the weaker the approval model, the easier it is for an attacker or an over-permissioned vendor integration to turn a single grant into broad data access. NHIMG’s SaaS API Token Security Guide covers the same lifecycle problem across SaaS tokens and connected apps, including revocation and hygiene.
How connected apps fail in the real world
Connected apps become dangerous when approval is abused, token hygiene is weak, or a third-party integration is trusted too broadly. Real incidents show that a valid OAuth relationship can be weaponised even when the Salesforce tenant itself is not “broken” in the classic sense. NHIMG’s OAuth and SaaS integration breaches guide is a useful reference point because it ties connected-app design to the failure patterns seen in integration-driven data theft.
When a connected app is abused, the impact is usually not limited to one login event. Attackers can use the granted access to enumerate records, export customer data, read support history, or chain into other SaaS systems that trust the same token or integration pattern.
Risk and Threat Considerations
Connected apps are attractive targets because they package delegated access in a form that often bypasses normal end-user scrutiny. If scopes are broad, tokens are long-lived, or approval controls are weak, a single malicious or compromised integration can expose large amounts of CRM data without needing to defeat Salesforce authentication directly.
Failure mechanism: An attacker or rogue integration abuses a legitimate OAuth grant, refresh token, or overbroad scope to read, export, or manipulate Salesforce data under an allowed app identity.
Impact: The result can be silent data exfiltration, vendor or supply-chain exposure, and persistence that survives password changes until the app grant or token is revoked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Connected apps rely on OAuth tokens and credential lifecycle controls. |
| AC-3 — Access Enforcement | Connected apps enforce what an external app can access in Salesforce. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Connected-app abuse is best detected through audit and event monitoring. | |
| Recommendation — Manage token issuance, rotation, expiration, and revocation for Salesforce connected apps. Enforce least-privilege scopes and app-level access decisions for every connected app. Review Salesforce events and login telemetry for unusual connected-app activity. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Connected apps authenticate external systems to Salesforce through OAuth flows. |
| API5 — Broken Function Level Authorization | App scopes determine which Salesforce functions the integration may invoke. | |
| Recommendation — Validate OAuth handling and revoke exposed or misused connected-app grants. Restrict connected-app scopes so integrations can only call approved functions. | ||
Practitioner Guidance
Why practitioners should care: Treat connected apps as standing access paths that deserve ownership, review, and retirement. If an app can still authenticate, it should be assumed to have meaningful operational reach until proven otherwise.
What to watch for: Watch for connected apps with broad scopes, stale approval, unused but still-authorised integrations, and vendors that can read more Salesforce data than their workflow requires.
Practitioner takeaway: The safest connected app is the one whose scopes, owners, and token rules are explicit enough to audit and narrow without breaking the business process.