For years, Connected Apps have been the backbone of integrating external systems with Salesforce. If you’ve ever implemented OAuth, JWT Bearer Flow, or Single Sign-On, chances are you’ve configured a Connected App.
But Salesforce’s integration story is evolving. With modern architectures—microservices, mobile apps, BFF (Backend-for-Frontend) patterns, and zero-trust security—connected apps are no longer enough. This is where External Client Apps step in.
This guide explains why external client apps exist, how they differ from connected apps, and when developers should adopt them.
The Problem with Traditional Connected Apps
Connected Apps were introduced at a time when integration landscapes were relatively straightforward. The assumptions were simple:
- One application equaled one integration
- OAuth flows were designed around interactive, UI-driven user journeys
- Client identity and user identity were treated as the same concern
For that era, the model worked well. But enterprise architectures have changed—dramatically.
Today’s systems are distributed, multi-client, API-first, and security-sensitive. And this is where Connected Apps begin to show their age.
The Architectural Friction We See Today
From an architect’s lens, the problem isn’t OAuth itself—it’s how tightly connected apps bind concerns that should be separate.
Modern platforms must support:
- Mobile apps, SPAs, backend services, and batch jobs
- User-based access and non-user (machine) access
- Fine-grained security policies that scale across environments
Connected apps struggle in this reality. Architects and developers regularly face challenges such as
- Difficulty managing multiple external clients with different trust levels
- OAuth flows that are inseparable from end-user authentication, even when no user interaction is required
- Poor alignment with headless, server-to-server, or API-only integrations
- Security policies that become fragmented and inconsistent as integrations grow
The “Overloaded Connected App” Anti-Pattern
To keep moving forward, teams often adopt a workaround that seems practical but introduces long-term risk. A single Connected App ends up carrying:
- JWT bearer flows alongside interactive OAuth
- Long-lived refresh tokens
- Multiple redirect and callback URLs
- Broad, catch-all scopes that exceed the principle of least privilege
From a governance perspective, this is a red flag. This approach may work short-term—but it increases operational risk, weakens security boundaries, and makes governance harder as systems scale.
The Architectural Takeaway
Connected Apps aren’t broken—but they are no longer sufficient as the primary integration abstraction for modern Salesforce ecosystems. As systems scale, architects must move toward:
- Clear separation of client identity vs. user identity
- Authentication models optimized for machine-to-machine trust
- Centralized, policy-driven security that doesn’t rely on over-permissioned OAuth apps
The future of secure Salesforce integrations lies not in stretching Connected Apps further but in evolving beyond them with purpose-built authentication and credential models.
What Are Salesforce External Client Apps?
External client apps establish a clear architectural boundary between external applications and Salesforce’s authentication and identity layer.
Rather than forcing every integration to behave like a UI-centric OAuth client, Salesforce enables architects to register external systems as first-class, non-interactive clients within the platform.
Conceptually, external client apps represent OAuth clients purpose-built for API-first, distributed architectures. They are designed to support:
- Backend and server-to-server integrations
- Native and hybrid mobile applications
- Enterprise-grade platform integrations
- Zero-trust security principles and least-privilege access models
Why Salesforce Introduced External Client Apps
From an enterprise architecture standpoint, Salesforce introduced External Client Apps to address modern identity and integration requirements, including:
🔐 Zero-Trust security models, where every client is explicitly authenticated and authorized
🧩 Composable architectures, enabling loosely coupled systems and integrations
📱 First-class support for mobile and native applications
⚙️ Secure service-to-service authentication without relying on user context
External Client Apps bring Salesforce in line with contemporary identity platforms such as Okta, Azure AD, and Auth0, where clients—not just users—are core identity constructs.
As a result, every external system interacting with Salesforce becomes
- Uniquely identifiable
- Fully auditable
- Independently secured and governed
This shift enables architects to design scalable, secure, and future-ready integration landscapes across the Salesforce ecosystem.
Connected App vs External Client App (Developer View)
| Area | Connected App | External Client App |
|---|---|---|
| Packaging Support | Support 1GP & 2GP. Require manual steps when using 2GP | No manual step for 2GP. 1GP not supported |
| Primary Focus | UI + OAuth | API-first integrations |
| Client Identity | Loosely defined | Explicit & managed |
| Best for | Web apps, SSO | Mobile, backend, microservices |
| Security Model | Mixed concerns | Strong client isolation |
| Token Strategy | User-centric | Client + user aware |
| Scalability | Limited | Designed for scale |
| Authentication Flows | Supports 1. Headless Identity Flows 2. OAuth 2.0 Web Server Flow 3. OAuth 2.0 User-Agent Flow 4. OAuth 2.0 Refresh Token Flow 5. OAuth 2.0 Token Exchange Flow 6. OAuth 2.0 JWT Bearer Flow 7. OAuth 2.0 Client Credentials Flow 8. OAuth 2.0 Device Flow 9. OAuth 2.0 Asset Token Flow 10. OAuth 2.0 SAML Bearer Assertion Flow 11. OAuth 2.0 Username-Password Flow. | Supports 1. Headless Identity Flows 2. OAuth 2.0 Web Server Flow 3. OAuth 2.0 User-Agent Flow 4. OAuth 2.0 Refresh Token Flow 5. OAuth 2.0 Token Exchange Flow 6. OAuth 2.0 JWT Bearer Flow 7. OAuth 2.0 Client Credentials Flow 8. OAuth 2.0 Device Flow 9. OAuth 2.0 Asset Token Flow |
Best Practices for Salesforce Integrations
🔐 Security Best Practices
- Design for Least Privilege
Grant only the minimum OAuth scopes and permissions required for the integration to function. Avoid broad access “just in case”—it increases risk and audit complexity. - Rotate Credentials Regularly
Periodically rotate client secrets, certificates, and signing keys. Automate rotation where possible to reduce human error. - Use Permission Sets, Not Profiles
Assign access using permission sets rather than profiles. This aligns with Salesforce’s modern access management model and simplifies governance. - Apply Network Restrictions
Where supported, restrict access to trusted IP ranges or known networks—especially for backend and service-to-service integrations. - Control Token Lifetimes
Configure access and refresh token expiration based on risk. Shorter lifetimes improve security; longer lifetimes should be justified and documented.
🛠️ Development Best Practices
- Adopt Source-Driven Configuration Management
Manage integration configurations using Metadata API, SFDX, or CI/CD pipelines to ensure traceability and consistency across environments. - Test OAuth Failure Scenarios
Beyond happy-path testing, validate behavior for expired tokens, revoked access, invalid scopes, and network failures. - Document Authentication Decisions
Record why a specific auth flow, scope set, or client type was chosen. This helps future developers and security teams understand trade-offs. - Design for Token Refresh and Revocation
Build integrations assuming tokens will expire or be revoked. Handle re-authentication gracefully without user disruption. - Standardize Naming Conventions
Use clear, consistent naming for External Client Apps to reflect their purpose, environment, and owning system.
⚙️ Operational Best Practices
- Perform Regular Access Reviews
Periodically audit which external applications and services have access to your Salesforce org. Remove unused or outdated integrations promptly. - Keep Integration Documentation Current
Update architecture diagrams, authentication flows, and scope definitions as Salesforce features evolve. - Plan for Platform Changes
Stay informed about Salesforce release updates—especially security and authentication changes that may impact integrations. - Evaluate Migration Opportunities
As Salesforce moves toward an External Client App–first model, assess whether existing Connected Apps should be migrated to improve security, scalability, and long-term supportability.
Summary
Salesforce is transitioning from Connected Apps to External Client Apps. While existing Connected Apps remain supported, Salesforce has announced that creation of new Connected Apps will be disabled by default starting Spring ’26, signalling a clear move toward External Client Apps as the long-term integration model.
Try moving your existing connected app in a phased manner for better connectivity with external applications.
References
Related Posts
- How to Navigate to Salesforce Experience Cloud from an ASP.NET App Without User Credentials
- Accessing External Credential Parameters of Named Credential in Salesforce Apex
- The Ultimate Guide to Automate Data Ingestion in Salesforce Data Cloud with Zapier
- Salesforce Outbound Message vs Platform Event: A Complete Architect’s Guide
- Salesforce Architect Guide to Mastering APIs for Scalable Integration
- Prevent Large Data Queries in Salesforce with Transaction Security Policies
- How to Use Graph API for Outlook-Salesforce Connection
- Ultimate Guide to Integrate Stripe with Salesforce CRM
- How to Seamlessly Integrate Shopify with Salesforce
- Create Jira Issue in Salesforce Apex with Jira Integration
- Integrate Slack in Salesforce for Real-Time Notifications
Need Help in Connected App Migration
Connect us to migrate the connected app to external client apps.
