How to review Salesforce connected apps and integration users: Find every OAuth app and lock it down

Every connected app in a Salesforce org holds tokens that can read customer data without a password or an MFA prompt, and the 2025 Salesforce data theft wave ran almost entirely through them. Attackers either stole tokens from a trusted integration vendor or talked staff into authorising an attacker-controlled app. This guide is a hands-on review procedure: find every connected app that has been used, decide which are trusted, tighten their OAuth policies, and rebuild the integration users behind them on least privilege. It is for Salesforce administrators and security teams. The wider org hardening picture is in the Salesforce Security Guide; this page is the review you run.

Key takeaways

• Start from usage, not configuration. The Connected Apps OAuth Usage page in Setup shows which apps are actually in use, how many users rely on each, and whether each is installed in the org; that list includes apps nobody configured.
• Install what you trust, block what you do not. Since early September 2025, uninstalled connected apps are no longer accessible to most users. Installing a trusted app lets you apply policies to it; blocking an app ends its active sessions and prevents new connections.
• The defaults are permissive. Out of the box, Permitted Users is "All users may self-authorize" and the refresh token policy is "Refresh token is valid until revoked". Change both for every app that touches sensitive data.
• One integration, one integration user. Salesforce's own guidance is a separate user per integration on the Salesforce Integration licence, with permissions granted through permission sets, never System Administrator.
• Two special permissions bypass the guard. "Approve Uninstalled Connected Apps" and the broader "Use Any API Client" let users use apps you have not installed or have blocked; grant them sparingly and review who holds them.

When you need this

• A vendor in your integration chain is breached. In the Salesloft Drift breach, stolen OAuth tokens for one chatbot integration were used to bulk-export records from hundreds of tenants and to search support cases for AWS keys, passwords and Snowflake tokens.
• Staff may have been socially engineered. In the ShinyHunters Salesforce campaign, callers posing as IT support walked employees through the connected app setup page to link a modified Data Loader to the tenant.
• Periodic review: quarterly, and before any audit of customer data access.
• Integration onboarding or retirement: every new or retired vendor integration should pass through this review.

Before you start

1. Confirm your permissions. Installing and uninstalling connected apps needs Customize Application and either Modify All Data or Manage Connected Apps. Use a named admin account, not a shared one.
2. List business owners for each known integration (CRM, marketing, support, data warehouse, AI tools) so you can confirm need quickly.
3. Use a sandbox for permission changes to integration users, as Salesforce recommends: start from minimal permissions and add only what the integration needs.
4. Collect provider IP ranges for each integration that publishes them; you will use them for login IP ranges.
5. Agree a communication plan. Blocking an app or revoking tokens cuts users off immediately; owners must know in advance.

Step-by-step

Steps 1 to 4 are read-only. Steps 5 to 7 change access; blocking and revoking take effect immediately.

1. Pull the usage list. In Setup, open Connected Apps OAuth Usage. Record each app, its user count and whether it is installed. Export or screenshot it as your baseline. Uninstalled apps with active users are your first questions.
2. Pull the configured list. In Setup, enter Connected Apps in Quick Find and select Manage Connected Apps. For each app, open Edit and record the OAuth Policies: Permitted Users, IP Relaxation and Refresh Token Policy.
3. Map each app to its integration user. For server-to-server integrations, identify the user the app runs as. Record that user's licence, profile, permission sets, login IP ranges and whether API Only is set. Note any integration running as a human administrator or shared across several integrations.
4. Check who can approve apps. List users and permission sets holding Manage Connected Apps, Customize Application, Approve Uninstalled Connected Apps and Use Any API Client. Each of these is a route for a new app to reach your data.
5. Decide and act on each app (changes access).
   • Trusted and needed: install it in the org if it is not installed, then tighten its OAuth policies (step 6).
   • Unknown or no longer needed: block it from the usage page. Salesforce states blocking ends active sessions immediately and prevents future connections.
   • Trusted but possibly exposed (vendor breach): revoke its tokens from the usage page, or per user on the user detail page under OAuth Connected Apps, and ask the vendor to reconnect after it has secured its token store.
6. Tighten OAuth policies (changes access). Under Manage Connected Apps, Edit, OAuth Policies:
   • Permitted Users: set "Admin approved users are pre-authorized" and assign access through a profile or permission set, as Salesforce recommends.
   • IP Relaxation: keep "Enforce IP restrictions" unless the integration genuinely cannot work with it; "Relax IP restrictions" removes a control that limits stolen-token use.
   • Refresh Token Policy: replace "Refresh token is valid until revoked" with "Expire refresh token if not used for n" or "Expire refresh token after n" for user-facing apps, so abandoned grants die on their own.
7. Rebuild integration users on least privilege (changes access). Give each integration its own user on the Salesforce Integration licence (Enterprise, Unlimited and Performance editions include five). In new orgs use the Minimum Access - API Only Integrations profile, where API Enabled and API Only are set and cannot be edited. Keep the profile to defaults, page layouts, login hours and login IP ranges, and grant object access through permission sets. Restrict login IP ranges to the provider's published ranges.

Verify it worked

• Re-open Connected Apps OAuth Usage: blocked apps show as blocked, every remaining app with users is installed, and user counts match the owners' expectations.
• Test each integration end to end after its policy and user changes, using the sandbox first and then production.
• Check login and API activity: review login history for each integration user to confirm logins come only from the expected IP ranges, and use Event Monitoring where licensed to confirm query volumes are normal. See the Salesforce Event Monitoring Detection Guide.

Rollback and common errors

• Revoked tokens cannot be restored: users or the vendor must re-authorise. Rollback for a wrongly blocked app is to unblock it and have users reconnect.
• Changing Permitted Users without assigning access: switching to admin-approved immediately stops users who are not assigned through a profile or permission set. Assign first, then switch.
• Tightening IP rules without the provider's ranges: the integration fails at its next login. Confirm ranges with the vendor before enforcing.
• Removing permissions in production first: integration failures surface as silent data sync gaps. Test in a sandbox and monitor sync jobs after the change.
• Forgetting the device flow: after the September 2025 change, existing users of uninstalled apps keep access unless the app uses the OAuth 2.0 device flow, so some apps break and others keep working. Check each rather than assuming.

Hardening afterwards

• Restrict who can approve apps: keep Manage Connected Apps and Customize Application to a small admin group, and treat Approve Uninstalled Connected Apps and Use Any API Client as privileged.
• Keep secrets out of records: the Drift attackers searched support cases for credentials. Scan and redact cases, notes and attachments.
• Alert on bulk export by integration users and on new app authorisations, and train support staff that real IT never asks for a connection code or MFA code.
• Ask vendors how they store your tokens and secure their source control, as part of third-party review.

Where identity fits: each connected app plus its integration user is one non-human identity with persistent API access. Record an owner, purpose, scopes, user, IP ranges and review date for each, and include them in access certification.

Small and large orgs: a small org with a handful of integrations can run the whole review in a day and fix integration users directly. A large org with dozens of AppExchange packages, regional admin teams and several data warehouse feeds should first block or restrict the highest-risk apps (uninstalled apps with users, anything with bulk export capability, anything running as an administrator), then work through integration users one owner at a time on a published schedule, because every change needs a sandbox test and a vendor conversation. In both cases, AI assistants and agent platforms that connect over OAuth belong in the same review as any other connected app; see the Securing Salesforce Agentforce Guide for the agent-specific controls.

Measure it: uninstalled apps with active users (target zero), integrations running as administrators (target zero), apps with non-expiring refresh tokens, holders of Use Any API Client, integration users without login IP ranges, and days since last review.

Practitioner checklist

• Export the Connected Apps OAuth Usage list as a baseline
• Record OAuth Policies for every app under Manage Connected Apps
• Install trusted apps and block unknown or unneeded ones
• Set Permitted Users to admin approved and apply a refresh token expiry policy
• Give each integration its own integration user with permission sets and login IP ranges
• Restrict Manage Connected Apps, Customize Application, Approve Uninstalled Connected Apps and Use Any API Client
• Revoke tokens for any app whose vendor reports a breach

Standards and references

• Salesforce Help: Manage OAuth access policies for a connected app
• Salesforce Help: Manage OAuth-enabled connected apps access to your data
• Salesforce Admins: Get ready for changes to connected app usage restrictions
• Salesforce Admins: Best practices for configuring your integration user
• MITRE ATT&CK: T1528 Steal Application Access Token
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Salesforce Security Guide · Salesforce Event Monitoring Detection Guide · How to detect use of a stolen OAuth refresh token · Securing Salesforce Agentforce Guide