Salesforce Security Advisory: Connected App & OAuth Fixes (Oct 2025)

After 700+ organizations lost over 50 million customer records through Connected Apps attacks throughout 2025, including Google (2.55M records), Coca-Cola (23M records), Cloudflare, Palo Alto Networks, and Zscaler, Salesforce implemented the most aggressive security changes in platform history.

Following their official security advisory to partners in August 2025, many admins are now wondering why users suddenly can't access familiar tools.

This guide explains exactly what changed and how to fix it.

What the hack? how this happened?

If you want to fill in with more context, before diving into this guide. I investigated, researched and published an article on Medium, covering a lot of ground, history and details.

TL;DR

What Changed: Salesforce eliminated OAuth Device Flow completely and now blocks uninstalled Connected Apps for most users.

Who's Affected: All Salesforce users without "Approve Uninstalled Connected Apps" or "Use Any API Client" permissions (System Admins auto-assigned).

What To Do:

1. Upgrade Data Loader to v64.1.0 immediately

2. Audit OAuth Usage for uninstalled apps

3. Install trusted apps, block suspicious ones

4. Configure proper access controls

Timeline: 3-week implementation recommended (audit → categorize → secure)

Why Did Salesforce Lock Down Connected Apps?

The numbers tell the story. Throughout 2025, attackers compromised 700+ Salesforce organizations through a combination of direct vishing attacks and the Salesloft-Drift supply chain breach. They used a devastatingly simple social engineering approach:

The Attack Pattern:

1. Target Salesforce admins via LinkedIn

2. Impersonate IT support in phone calls

3. Guide victims to authorize fake "Data Loader" apps

4. Extract sensitive data through bulk API queries

5. Search stolen data for AWS credentials and passwords

Major Victims:

• Google: 2.55M records stolen

• Coca-Cola Europacific Partners: 23M records

• Cloudflare, Palo Alto Networks, Zscaler, Proofpoint, Tenable

• Hundreds of others documented in threat intelligence reports

The bottom line: Connected Apps' "trust-by-default" model made social engineering attacks trivially easy. Users could authorize any app globally without admin oversight.

What Actually Changed in September 2025?

Here's what I discovered analyzing the official Salesforce documentation published September 2025:

• Before Sep 2025: User Request → App Authorization → Immediate Access

• After Sep 2025: User Request → Permission Check → Admin Gate → Controlled Access

Uninstalled Connected Apps Blocked

• Who's affected: All users except those with new permissions

• What's blocked: Apps not formally installed by admins

• Exception: Existing users grandfathered in (except Device Flow)

Why Was Device Flow Completely Eliminated?

Unlike other restrictions with exceptions, OAuth Device Flow faced total elimination.

Device Flow's Fatal Flaw: Device Flow allowed users to authorize apps on separate devices (phone vs. computer). This created a perfect social engineering scenario. Attackers could say "Just enter this code to help us fix your account", and users had no direct verification of what app they were actually authorizing.

☝️ Watch: Video breakdown of how the social engineering attack worked (August 2025)

The Complete Shutdown Timeline:

• September 2, 2025: Device Flow support completely removed

• Data Loader: Required immediate upgrade to v64.1.0

• All existing sessions: Terminated immediately.

• No exceptions: Even "Use Any API Client" cannot bypass.

Official Salesforce Statement (September 2025): "There will be no exceptions or extensions to this removal."

Understanding App Types

Before you plan an audit or fix, let’s understand that Salesforce distinguishes between installed and uninstalled apps:

App Status	Admin Review	September 2025 Impact
Installed	✅ Formally approved/deployed/installed by admin	No impact - continues working
Uninstalled	❌ User-authorized only	Major restrictions

How to check?

Navigate to Setup → Connected Apps → OAuth Usage.

Apps showing an "Install" button are uninstalled. This process is documented in Salesforce's official audit guidance (Article 005132365, September 2025).

• Installed apps = Formally added to your org by an admin (AppExchange, manual Connected App, External Client App, or package deployment)

• Uninstalled apps = Authorized by users via OAuth without formal admin installation (appear only in OAuth Usage)

Why this matters now?

September 2025 changes primarily target uninstalled Connected Apps. Installed apps have clear admin governance and continue working normally. External Client Apps are secure-by-default in both local and packaged states.

Expanded comparison:

Aspect	Installed App	Uninstalled App
Admin Review	✅ Formally approved	❌ User-authorized only
Org Visibility	✅ Appears in Manage Connected Apps	❌ Only in OAuth Usage
Security Vetting	✅ Assessed by admin	❌ Ad-hoc end-user decision
Access Control	✅ Profiles/Perm Sets	❌ Individual, harder to govern
Policy Enforcement	✅ Admin-defined policies	❌ Limited policy control

How apps achieve each status?:

Installed status (any of):

1. AppExchange install → appears in Manage Connected Apps

2. Admin creates a Connected App (App Manager → New Connected App)

3. External Client App created (Apps → External Client Apps) as Local or Packaged

4. Package/metadata deployment via DevOps

Uninstalled status:

1. Users authorize third-party apps directly via OAuth (no prior install)

2. Developers/testers run OAuth locally against org without installing

How Do the New Permissions Actually Work?

Salesforce now uses a layered security model for Connected Apps. Here are your three main tools, explained simply:

1. Approve Uninstalled Connected Apps

• What it does: Lets a user authorize apps that aren’t installed in your org yet.

• Who gets it: By default, only System Administrators. You can assign it to others, but only do so for trusted integration managers.

• Risk: Moderate. Anyone with this can allow new apps, so keep it tightly controlled.

2. Use Any API Client

• What it does: Lets a user bypass all Connected App restrictions—no matter what.

• Who gets it: No one by default. Only assign for rare, “break-glass” exceptions (e.g., a critical integration that can’t work any other way).

• Risk: High. This overrides nearly all security controls. Remove ASAP after use.

3. API Access Control (Deny-by-Default)

• What it does: Org-wide setting that blocks all Connected App access unless an app is pre-authorized by an admin.

• How to enable: Not on by default. You must request activation from Salesforce Support.

• Risk: Low (if planned). This is the most secure option, but enabling it without prep will break all unapproved integrations. Always test in sandbox first.

• Reversibility: Technically possible via support, but treat as a “one-way gate”—undoing it is complex and disruptive.

What Do Users Actually See?

User Type	App Status	Experience	Admin Action
Standard User	Uninstalled	❌ "Requires approval"	Install app OR grant permission
System Admin	Uninstalled	✅ Can authorize	None (has permission)
Any User	Installed	✅ Works normally	None

Now that you know what users and admins will experience, here’s a quick comparison and cheat sheet for planning your rollout and permission strategy:

Option	Scope	Default Availability	What it Allows	Who Should Get It	Risk Level
Approve Uninstalled Connected Apps	User-level	System Admin only	Authorize uninstalled apps	Trusted integration managers	Medium
Use Any API Client	User-level	Not assigned	Bypass all restrictions	Exception-only users	High
API Access Control	Org-wide	Off by default	Deny-by-default for all apps unless pre-approved	Security-mature orgs	Low

How to Use These (Admin Cheat Sheet)

• Short-term unblock: Temporarily grant “Approve Uninstalled Connected Apps” to trusted admins while you migrate to installed apps.

• Emergency/break-glass: Assign “Use Any API Client” only as a last resort, and revoke it immediately after use.

• Long-term security: Plan for API Access Control as your end state. Inventory integrations, pre-authorize apps, test in sandbox, then enable in production.

TL;DR:

• Fewer people, more power, less time. Remove permissions when done.

• “Use Any API Client” is a fire extinguisher: only for emergencies.

• API Access Control is the gold standard—plan, pilot, then switch.
  

How Do You Handle Common Scenarios?

Scenario 1: Marketing team can't access their analytics integration

1. Check OAuth Usage for the analytics app

2. Click "Install" if it's a trusted tool

3. Set "Permitted Users" to "Admin approved users are pre-authorized"

4. Create "Marketing Analytics Access" permission set

5. Assign permission set to marketing team only

Scenario 2: Data Loader Migration: Users getting authentication errors in Data Loader

After the OAuth 2.0 Device Flow was removed September 2, 2025.

Official changes (September 2, 2025):

• Removed completely: OAuth 2.0 Device Flow and OAuth 2.0 User-Agent Flow

• New default: OAuth 2.0 Web Server Flow with PKCE

• No exceptions: Even "Use Any API Client" cannot restore Device Flow

Solution:

1. Upgrade to Data Loader v64.1.0 (mandatory)

2. For auto-installed Connected App: No additional config needed

3. For custom Connected App:

   • Set Callback URL: http://localhost:7171/OauthRedirect

   • Enable PKCE: "Require Proof Key for Code Exchange (PKCE) Extension"

   • Disable: "Require secret for Web Server Flow"

   • Disable: "Enable for Device Flow" (security requirement)

Alternative: If v64.1.0 unavailable, use v64.0.2 with custom External Client App configuration.

Why External Client Apps Are Superior?

External Client Apps weren't significantly affected because they already implement "secure-by-default" principles.

Factor	Connected Apps	External Client Apps
Default Security	Global by default	Local by default
Admin Control	Manual configuration	Built-in governance
New Development	Legacy approach	Modern architecture

What Are the Key Error Messages?

When users hit restrictions, they'll see:

Standard Error:

"We can't authorize you because of an OAuth error. For more information, contact your Salesforce administrator."

• Technical: OAUTH_APPROVAL_ERROR_GENERIC

• URL Parameter: error=invalid_client&error_description=app+must+be+installed+into+org

Data Loader Errors (Post-September 2):

"Unable to complete browser based OAuth login"

• "1800: There was a problem in setting up your remote access"

• "OAUTH_APPROVAL_ERROR_GENERIC: An unexpected error has occurred during authentication"

• Cause: Still configured for eliminated Device Flow

Browser Extensions Impact:

Browser extensions (Chrome, Firefox, Edge) behave exactly like Connected Apps and face the same restrictions. If your browser extension stops working, the Connected App it uses needs to be installed by an admin.

How to Verify Restrictions Are Active

Official testing method (documented September 2025):

1. Create a test user account in your org

2. Have test user attempt to authorize an uninstalled Connected App

3. Expected result: OAuth error with "app must be installed into org"

4. Confirmation: If blocked with this specific error, restrictions are working

💡 What This Means for You

If you're a Salesforce Admin:

• Expect user complaints about app access in the coming weeks

• Budget 2-3 weeks for OAuth Usage audit and cleanup

• Plan Data Loader v64.1.0 rollout immediately

If you're a Developer:

• Migrate away from Device Flow authentication now

• Use External Client Apps for all new integrations

• Implement PKCE for Web Server Flow implementations

What Should You Do Right Now?

Based on official Salesforce guidance published September 2025, here's your implementation roadmap:

Week 1: OAuth Usage Assessment

1. Navigate to Setup → Connected Apps → OAuth Usage

2. Identify uninstalled apps (look for "Install" buttons)

3. Click User Count numbers for detailed usage analysis

4. Document business justification for each app

Week 2: App Categorization

1. Trusted apps: Click "Install" button from OAuth Usage

2. Untrusted apps: Click "Block" to end all sessions (could be done ASAP also, if you are sure).

3. Data Loader: Upgrade all users to v64.1.0

4. Plan permission assignments carefully

Week 3: Security Configuration

1. Configure installed apps with "Admin approved users are pre-authorized"

2. Assign access through profiles and permission sets

3. Test with non-admin users to verify restrictions work

4. Deploy user communication plan

Ongoing Governance: Monthly & Quarterly Reviews

Monthly tasks:

• Review Connected Apps OAuth Usage for new uninstalled apps

• Audit "Approve Uninstalled Connected Apps" permission assignments

Quarterly tasks:

• Comprehensive Connected App security review

• User access certification for installed apps

• Permission cleanup for temporary assignments

Long-term strategy:

• Use External Client Apps for new integrations

• Plan gradual migration from Connected Apps where beneficial

• Implement governance processes based on official guidance

References & Further Reading

My Analysis:

• My original investigation: Why Million $ Security Stack Failed Against a $45 Voice Phishing Attack (Medium, August 2025)

• Video: How the Social Engineering Attack Worked (August 2025)

Official Salesforce Documentation:

• Prepare for Connected App Usage Restrictions - Article 005132365 (September 2025)

• Data Loader OAuth 2.0 Device Flow Removal - Article 005132367 (September 2025)

• Get Ready: Changes to Connected App Usage Restrictions - Salesforce Admin Blog (August 2025)

Threat Intelligence & Security Research:

• Google Threat Intelligence: Widespread Data Theft via Salesloft Drift (July 2025)

• ReliaQuest: ShinyHunters Targets Salesforce Amid Scattered Spider Collaboration (August 2025)

• Salesforce Attacks in 2025: Comprehensive Breach Timeline (September 2025)

• Reco.ai: What the Salesloft Drift and ShinyHunters Breaches Reveal (July 2025)

Queries?

This whole thing could be overwhelming to process, lets us know if we could be any further help