The App Is the Gatekeeper
Module 1 of 5 in the chapter External Client Apps, Tokens and Their Lifecycle, chapter 13 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: What is the app that every OAuth flow goes through, and how do you see all of them?
Every flow went through an app
Section titled “Every flow went through an app”Look back over Part 2. Client credentials at the food festival (chapter 8). The Burger House’s web server flow (chapter 9). The device flow on the TV (chapter 9). The golden pass (chapter 11). Social sign-on, from Salesforce’s side (chapter 10). Every one of them had something in common: an app in Salesforce. Its client ID was in every request. Its settings decided what the flow could do.
Think of it as the business licence at the festival’s entrance. Every vendor needs one. The entrance checks it before it hands anybody a wristband. Whoever controls the licences controls who gets in, and what they can do.
That’s why this chapter matters. When things went wrong in 2024 and 2025, as module 4 shows, they went wrong at the app: an app someone approved, or the tokens an app was holding.
What an external client app is
Section titled “What an external client app is”In Salesforce’s words, external client apps are “packageable frameworks to enable a third-party application to integrate with Salesforce using APIs and security protocols”, with SAML and OAuth (S1). You made them in chapters 7, 8, 9 and 11.
Every external client app has two halves, set by two different people.
Settings: the developer. What the app is: OAuth on, its callback URL, its scopes, which flows it uses, PKCE, rotation. Settings are packaged and distributed with the app (S1).
Policies: the admin. How this org lets it in: who may use it, from where, for how long, how strongly they must have signed in. Salesforce is precise: policies “are never packaged, and only affect the admin’s local org. Subscriber org admins can’t edit app settings” (S1).
So the developer can’t decide your org’s policies, and you can’t change their app’s settings. That separation is the point. The people who build an app and the people who let it into an org are often different companies.
And the secrets? The OAuth settings are split in two: a global file with the consumer details, which “can never be packaged”, and a local one that refers to it (S1). The secret doesn’t travel.
Local or packaged
Section titled “Local or packaged”An external client app is either local, made and used in one org, like every app in this course’s labs, or packaged, for distribution to other orgs (S1).
One thing about local apps catches people out: “Local external client apps aren’t copied to a new sandbox when you clone or refresh a sandbox” (S1). So when you refresh a sandbox, plan to recreate the local apps your tests need.
The connected apps orgs still have
Section titled “The connected apps orgs still have”Before external client apps, there were connected apps, and most orgs still have plenty. Here’s where they stand, with dates:
- Since Spring ‘26, creating a new connected app needs a request to Salesforce Support; existing ones keep working (S3).
- In Summer ‘27, “Salesforce is ending support for connected apps. Connected apps will keep working, but Salesforce will no longer fix bugs or provide support for the integrations and authorization flows that use them” (S2).
- The way across: in App Manager, open the connected app and click Migrate to External Client App (S2).
So: nothing breaks tomorrow, but every connected app in your org needs a plan before Summer ‘27.
Seeing every app
Section titled “Seeing every app”Here’s a question I’d put to any admin. How many apps can reach your org’s data right now? And which of them have the security controls switched on?
Most people don’t know. Salesforce gives you two places to find out:
- The Insights page. From Setup, Insights: “Review the security controls of the external client apps and connected apps in your org”, both enabled and disabled, “whether they are local or developed outside your org” (S5). Find the apps missing controls, and Configure Security Posture shows which. For your own app, turn them on; for a packaged one, ask its developer, or disable it until they update it (S5).
- The OAuth Usage page. For external client apps: who’s connected, and the power to block an app (S9).
Why bother? Salesforce describes the risk of not looking: “A previously authorized but now insecure third-party application continues to programmatically harvest sensitive records long after its business utility has ended” (S9). An app nobody remembers is still a way in.
Test knowledge. The exam guide aligns to Summer ‘23 and says connected apps. In my experience, know what the app controls in every OAuth flow, and that its admin policies are separate from its settings.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video setting up an app, then a connected app, and calling the API with it from Postman. The note under the video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 2: who may use it, and how. The policies.
What an architect decides here
Section titled “What an architect decides here”- Local or packaged, for each app you build.
- A plan for every connected app before Summer ‘27.
- Who looks at the Insights and OAuth Usage pages, and how often.
Explore
Section titled “Explore”- External Client Apps (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Migrate All Connected Apps to External Client Apps (Release Update) (opens in a new tab) (Winter ‘27 release notes; checked 2026-11-07)
- Monitor App Security Controls on the Insights Page (opens in a new tab) (Winter ‘27 release notes; checked 2026-11-07)