Choosing a Flow
Module 5 of 8 in the chapter Trust, Identity, and Integration Security, chapter 13 of the Integration Architect course. Each module stands on its own. Previous: One Integration, One Identity · Next: What to Build On
The question this module answers: Which OAuth flow should an integration use to get its token, and how do you choose?
Why There Are Flows at All
Section titled “Why There Are Flows at All”Every flow solves the same problem: getting a token to a caller without handing anyone a password they shouldn’t have. Salesforce’s own guidance puts the principle first: “We recommend avoiding the user-agent and username-password flows because they transmit credentials. Instead, choose a flow that frees the app from having to manage, store, and protect credentials” (OAuth Authorization Flows (opens in a new tab), Salesforce Help, checked 2026-11-07).
There are a lot of flows. An integration architect needs two in full, one more in outline, and a line on the rest. Two stories carry the two that matter.
The Food Festival
Section titled “The Food Festival”Think of a food festival. There are dozens of food stalls, and the people cooking don’t have time to check who you are or take your money. That’s done somewhere else. So you go to the entrance, show who you are, pay, and get a wristband. Then you go to any stall, show the wristband, and they serve you. The stall never sees your ID. It just checks the wristband, and the wristband only lasts for a while.
That’s the client credentials flow, and it’s the usual answer when there’s no person, just one system calling another. The integration has its own credentials, a client ID and a secret from its External Client App. It shows them at the entrance, Salesforce’s token address, and gets an access token. Then it shows the token at any API, and the API serves what the integration user may see, and nothing more.
Prove who you are once, at the entrance; show the wristband at every stall.
When I first taught this, the story was told with a username and password at the entrance. That’s the flow that retires in 2027. Salesforce describes client credentials as “a more secure alternative to the OAuth 2.0 username-password flow”: the same shape, with the program’s own credentials instead of a person’s. It still runs as someone, an integration user you choose (module 4), and chapter 4 walks it step by step.
At Steve Trucking, this is how the integration layer signs in for its own work: manifests in, status out.
The Burger House
Section titled “The Burger House”Now a person. Say you’re at the burger house, an app, a web app on its own server. It makes the burgers: that’s its own data. But you want a drink with your burger, and your drink is next door, at the food festival, Salesforce, where you have your own account. The burger house offers to fetch your drink for you and serve the two together. Your drink is your Salesforce data. How does the burger house get your data without you giving it your password?
That’s the web server flow. The burger house sends you to Salesforce’s login page. You sign in there, only there: the only one you give your password to is Salesforce. Salesforce gives you a code, and you carry it back to the burger house. The burger house takes the code to Salesforce and trades it for two things: a wristband for now, and a refresh token for later. Then it fetches your data, acting for you. The burger house never sees your username and password.
The code travels through your browser, though, and a code that travels can be copied. So the web server flow now comes with PKCE, Proof Key for Code Exchange. Here’s one way to picture it. Before the burger house sends you to Salesforce, it writes a pickup word on a slip of paper it keeps, and sends Salesforce only the word’s fingerprint. When it comes back with your code, it has to show the slip. Salesforce checks that the word matches the fingerprint. Someone who copied your code on the way has the code, but not the slip, so they get nothing.
The person signs in only at Salesforce; the pickup word proves the app is the one that asked.
PKCE isn’t optional anymore in practice. Salesforce calls it “an essential industry security practice for OAuth 2.0” and now requires it for all ISV client apps, for the web server flow and its relatives (Enabling PKCE for OAuth for Salesforce External Client and Connected Apps (opens in a new tab), Salesforce Help, updated September 22, 2026, checked 2026-11-07). Turning it on for an existing app “requires a coordinated change on both the server and clients,” so plan it like any cutover.
At Steve Trucking, the crews’ mobile app is the person-present case: a driver signs in, and the app acts for that driver.
Acting for a User Who Isn’t There
Section titled “Acting for a User Who Isn’t There”Sometimes there’s no person signing in, but the call must still carry a named user, because the record has to show who did it, or because only that user may see it. Or your security team wants the caller to sign with a certificate rather than send a secret.
That’s the JWT bearer flow. I’ve likened flows like this to a food delivery truck: the food arrives for you when you’re not even there. The integration builds a small token naming the user, signs it with its private key, and sends it; Salesforce checks the signature with the certificate on the External Client App (chapter 12). In Salesforce’s words, it “uses a certificate to sign the JWT request and doesn’t require explicit user interaction. However, this flow does require prior approval of the external client app.” Nobody is there to approve it at run time, so the approval has to be in place beforehand.
At Steve Trucking, that’s the master design’s rule: client credentials for the integration layer’s own work, and JWT bearer where a change must carry a named user. The Identity and Access course does JWT bearer hands-on, with the certificate.
The Rest, in a Line
Section titled “The Rest, in a Line”- Token exchange. When another identity provider already issued a token, trade it for a Salesforce token, “to simplify your integration patterns” in architectures with “a central identity provider along with multiple apps and microservices.”
- The SAML assertion flow. Trade a SAML assertion from single sign-on for a token; it’s the one flow that doesn’t need an External Client App.
- The device flow. For a TV or a device with no keyboard. From November 30, 2026, only for local External Client Apps (module 3). Not for integrations.
- The refresh token flow. How the burger house uses its refresh token later. That’s module 7.
And two to retire, both on February 20, 2027 (module 1): the username-password flow, replaced by client credentials or the web server flow; and the user-agent flows, replaced by the web server flow with PKCE.
The Decision
Section titled “The Decision”Three questions pick the flow for almost every integration.
Is a person there? Must it be a named user or a certificate? Is there already a token? Otherwise, client credentials.
| The caller | The flow | Instead of |
|---|---|---|
| A system, for its own work | Client credentials | The username-password flow |
| A web app, for a person | Web server with PKCE | The user-agent flow |
| A system, as a named user, or signing with a certificate | JWT bearer | A stored user’s password |
| A system holding another identity provider’s token | Token exchange | A second sign-in |
Every flow on this table still needs the rest of the chapter: an identity of its own, the narrowest scopes, and a token treated as the design decision it is.
Test knowledge. Match the flow to the caller: client credentials for server-to-server with no user (an integration user runs it); the web server flow with PKCE when a person signs in to a web app (the app trades a code for access and refresh tokens; PKCE protects the code); JWT bearer for server-to-server as a named user, signed with a certificate, with the app pre-approved; token exchange for a token from another identity provider; the device flow only for limited-input devices. The username-password and user-agent flows retire February 20, 2027. The SAML assertion flow is the one flow that doesn’t need an External Client App.
Watch it on video
Section titled “Watch it on video”In 2023 I made two videos on this for the Identity and Access series: when to use single sign-on and when OAuth, and the OAuth flows told in a beer garden. This course tells the same story at the food festival. The notes under the videos say what’s still right and what’s changed since.
What an Architect Decides Here
Section titled “What an Architect Decides Here”- For each integration: is a person there, and if not, whether its calls must carry a named user.
- The flow for each, from the three questions, with the reason written down.
- Every integration still on a retiring flow, and its move before February 20, 2027.
- PKCE on every web server flow, and the coordinated change to turn it on.
- Who approves a JWT bearer app, and which users it may act for.
Explore
Section titled “Explore”- OAuth Authorization Flows (opens in a new tab): Salesforce Help, every flow and when to use it (checked 2026-11-07)
- Enabling PKCE for OAuth for Salesforce External Client and Connected Apps (opens in a new tab): Salesforce Help, September 22, 2026 (checked 2026-11-07)
- Who’s Calling In: chapter 4, client credentials step by step