Last week I told you that Salesforce Hosted MCP Servers are configured on just two Setup pages: the External Client App and MCP Servers. Today we build the first one, and I want to convince you of something before we start: this is not the boring prerequisite before the fun part. This is the part that makes everything else safe.
The External Client App is your OAuth bridge — the front door between an MCP client like Claude and your org. Get it right and every later step inherits its safety. So let’s build it carefully, in a sandbox, the way I built mine for my Urla Shoes org.
What the External Client App actually is
When Claude connects to your hosted MCP server, the very first conversation isn’t about data or tools. It’s about identity: who is this, and what are they allowed to ask for? The External Client App is the org’s answer. It’s the modern, more secure evolution of the connected app pattern, and it defines three things:
- That this specific client may request access to your org at all.
- How the sign-in happens — the OAuth flow, hardened with PKCE.
- The maximum permission the client can ever hold — the scopes.
Notice what it does not define: which records a user can see. That stays with your existing security model — profiles, permission sets, sharing rules. The External Client App is a gate, not a new set of keys. A user who connects through it can never do more than they could do logged in normally. Usually, thanks to scopes, they can do considerably less.
Step by step: creating the app
Work in a sandbox first. Always. Here’s the walk-through.
Step 1: Create the External Client App
In Setup, search for External Client Apps and create a new one. Give it a name that will make sense to a colleague reading an audit log two years from now — I used something plain like MCP Client Bridge. Fill in the basics (name, contact email) and enable OAuth settings for the app.
Names matter more than people think. “Test App 2” tells your future self nothing. “MCP Client Bridge” tells them exactly what breaks if it’s deleted.
Step 2: Configure the OAuth flow with PKCE
Set up the authorization code flow and require PKCE — Proof Key for Code Exchange. The acronym is scarier than the idea, so here’s the plain version.
In a classic OAuth flow, the client exchanges a temporary code for an access token. If someone intercepts that code, they can try to replay it. With PKCE, the client invents a fresh secret at the start of each sign-in, sends a fingerprint of it up front, and must present the original secret to complete the exchange. A stolen code is useless without the secret — and the secret never travelled over the wire.
Why do we insist on this here? Because MCP clients are public clients — apps that live on user devices and can’t safely hold a permanent client secret. PKCE is the industry-standard answer for exactly that situation, so make it non-negotiable in your configuration.
Step 3: Choose least-privilege scopes
This is where I want you to slow down. OAuth scopes are the ceiling on what a connected client can request — and your job is to set that ceiling as low as the use case allows.
The habit I want to break: grabbing full scope “so everything just works.” I understand the temptation; I felt it too when a flow failed and I wasn’t sure why. Resist it. Start with the minimum — API access plus refresh-token support for a smooth reconnect experience — and add a scope only when a real, observed failure tells you it’s missing.
Here’s the reasoning, in one sentence: a scope you never granted is a mistake that can never happen. If the MCP client only ever needs to read data and call the tools you expose, then a token limited to that can’t be leveraged into anything more — not by a bug, not by a clever prompt, not by a compromised device. Least privilege isn’t paranoia; it’s just not paying for risk you don’t use.
Step 4: Set the policies
Review the app’s policies: which users may authorize it (you can restrict by profile or permission set), how long refresh tokens live, and whether admin pre-approval is required. In a sandbox, keep it permissive enough to test. Before production, tighten it: decide deliberately who in your org should be connecting AI clients at all, and encode that decision here rather than in a memo nobody reads.
Step 5: Note what the MCP Servers page will need
Once saved, your External Client App is the OAuth bridge that the MCP Servers Setup page will lean on when you activate a server and select tools. That’s Part 2 of this setup — the capability side of the house. Today we finished the identity side.
Why this design beats a service account
Let me name the alternative, because most orgs have lived it: the integration user. One shared account, one powerful profile, one set of credentials that every integration borrows. It’s how middleware has connected to Salesforce for years, and it has three quiet problems that the External Client App design solves outright.
Attribution. With a service account, every action in the log says the same name. When something goes wrong — or when security asks who read a sensitive record — you genuinely cannot say. With hosted MCP, every call runs as the authenticated user, and the audit trail names a real person. Twenty years in education taught me you can’t improve what you can’t attribute; the same is true of security incidents.
Blast radius. A service account is usually over-permissioned, because it must serve every integration’s superset of needs. Compromise it and you’ve compromised everything it can touch. With per-user OAuth plus least-privilege scopes, a compromised token is bounded twice: by one user’s permissions and by the scope ceiling. The worst case shrinks from “the org” to “what this one person could read anyway.”
Honest permissions. The service-account pattern forces middleware to re-implement your sharing model in code — and re-implementations drift. The bridge pattern never impersonates and never simulates: the org enforces its own rules, per user, per call, the same way it does for every login. There’s nothing to drift.
If you take one idea from today, take this: the External Client App isn’t bureaucracy in front of the fun part. It’s the reason you’ll be able to say “yes” when someone asks whether connecting an AI to the org is safe — and explain exactly why.
Your next step
Create the app in a sandbox today, even if you don’t activate a server yet. Walk through the OAuth sign-in from an MCP client, watch the consent screen list precisely the scopes you chose, and read the login history afterwards — your own name, attached to your own session. That little loop builds more genuine confidence than any checklist.
Next in the series: MCP Servers, the second Setup page — activating a hosted server and choosing which tools it exposes, including the moment my own Apex showed up in Claude’s tool list. See you there.