OAuth
Module 3 of 7 in the chapter SSO or OAuth? Choosing the Mechanism, chapter 5 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: Priya is still there and still in charge, but now another piece of software reaches into Salesforce for her. Why does that need OAuth, and which flow?
Two more rows that begin with a person
Section titled “Two more rows that begin with a person”The top row of the map was Priya in a browser on Salesforce’s own pages. The next two rows still begin with Priya, but something else reaches Salesforce.
- A mobile app. Priya opens an app on her phone. The app draws its own screens, and asks Salesforce’s API for the data.
- Another web server. Priya goes, in her browser, to some other web application, and she wants that application to reach into Salesforce for her. Think of Workbench, a tool many admins use, or an email plug-in that logs her emails against Salesforce records.
In both rows, the human starts it and the human is around. But the thing reaching Salesforce isn’t Salesforce’s own page in her browser. It’s someone else’s software, and it’s asking for her data.
The little line
Section titled “The little line”Go back to the whiteboard from module 2. Browser to system A, browser to Salesforce, and maybe an identity provider. Only arrows from the browser: single sign-on.
Now the moment we want system A to talk to Salesforce directly, server to server, this is different. I draw one more line, a little line from system A to Salesforce.
That little line needs OAuth. We still have the human around, and it’s still started by the human, but now one system is calling another. A redirect can’t carry that; there’s no browser on that line. System A has to present something to Salesforce’s API, and it has to be something Salesforce trusts.
Why not just give it her password?
Section titled “Why not just give it her password?”The obvious answer is to give system A Priya’s username and password, and let it log in as her. That’s the worst thing you can do. Every time it wants some data, it passes in her username and password. Salesforce’s own Help says why it’s wrong: the app “effectively impersonates you, with precisely the same access to your data”, and if you stop trusting it, you have to change your password (S1).
OAuth is the way out. Priya proves who she is to Salesforce herself, on Salesforce’s own login page, and says yes to the app. The app gets a token: limited, revocable, with no password inside it. If she stops trusting the app, she revokes the token, and nothing else changes. Chapter 8 tells that story with the beer garden.
The flow for both rows: web server with PKCE
Section titled “The flow for both rows: web server with PKCE”So which OAuth flow? For both of these rows, Salesforce’s answer today is the same: the web server flow with PKCE. In its own words, for end user login and authorization, “use the OAuth 2.0 web-server flow with the Proof Key for Code Exchange (PKCE) extension” (S2).
In one line: the app sends Priya’s browser to Salesforce’s login page; she logs in and approves; Salesforce sends the browser back to the app with a short-lived code; and the app exchanges that code, server to server, for the token. PKCE (Proof Key for Code Exchange, said “pixie”) adds a one-time secret the app makes for each login, so a stolen code is no use to anyone else. Since July 2026, PKCE is required for new apps that use this flow (S9).
Notice that the redirects are still there. The browser is still the broker for the part where Priya proves who she is. The difference is the last step, the little line, where the app picks up the token. Chapter 9 walks through it hop by hop, with the Burger House.
Test knowledge. The web server flow is the one to really learn. If you can get this one, all the other ones are simpler. Know that it’s the flow for a person using an app or a third-party web server, and know what PKCE adds.
If you learned it another way
Section titled “If you learned it another way”If you learned this a few years ago, you may have learned that a mobile app uses the user-agent flow, where the token comes straight back to the browser. I taught it that way too. Salesforce is retiring the user-agent and hybrid user-agent flows on February 20, 2027, because they “directly expose access tokens to the browser”, and they’re already blocked in orgs created in Winter ‘27 (S3). Use the web server flow with PKCE instead, for mobile apps too.
The exam guide, which is aligned to an older release, still lists the user-agent flow among the flows to know (IDP-1). So know what it is and why it’s going, but design with the web server flow.
So she isn’t asked every time
Section titled “So she isn’t asked every time”There’s one more piece that rides along. When the app gets its access token through the web server flow, it can get a refresh token with it. This little refresh token comes for the ride. When the access token expires, the app doesn’t need to talk to the human again. It presents the refresh token and gets a new access token.
That’s why your TV app doesn’t ask you to log in every evening. And it’s why refresh tokens need care: Salesforce now limits how long one can sit unused, and chapter 13 covers that lifecycle.
When the person is already signed in somewhere else
Section titled “When the person is already signed in somewhere else”One more case is worth a line. In a bigger architecture, Priya may already be signed in to a central identity provider, with several apps and services passing her identity along. Salesforce has a token exchange flow for that: it exchanges a token from that identity provider for a Salesforce one (S1). Same row, a different way to get the token. Chapter 11 teaches it.
On the map
Section titled “On the map”On the grid of every way to sign in (module 6), this module is one set: a person, through an app. The web server flow with PKCE is the one to learn; the user-agent flow is on its way out.
Watch it on video
Section titled “Watch it on video”Three of my 2023 videos go with this module: the web server flow told at a beer garden, the same flow step by step in a demo, and the refresh token. The note under each video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 4: what happens when the browser goes away, and there’s no person there at all.
What an architect decides here
Section titled “What an architect decides here”- Every app and server that reaches Salesforce for a person, listed: mobile apps, third-party web apps, plug-ins.
- The flow for each: web server with PKCE by default; no passwords handed over, no user-agent flow.
- Whether the app keeps a refresh token, and how long it may sit unused (chapter 13).
- Where each app is registered in Salesforce, as an External Client App (chapter 13).
Explore
Section titled “Explore”- OAuth Authorization Flows (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- OAuth User-Agent and Hybrid User-Agent Flows Retirement (Release Update) (opens in a new tab) (Salesforce Release Notes, Winter ‘27; checked 2026-11-07)
- OAuth Security Controls Are Enforced for New External Client Apps and Connected Apps (opens in a new tab) (Salesforce Release Notes, Summer ‘26; checked 2026-11-07)