Once You Know This One
Module 6 of 6 in the chapter OAuth: The Base Pattern, chapter 8 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: With so many OAuth flows, why do most of them look the same?
Oh my gosh, so many flows
Section titled “Oh my gosh, so many flows”Open Salesforce’s list of OAuth flows for the first time, and it’s a lot. Web server, client credentials, JWT bearer, SAML bearer assertion, SAML assertion, device, asset token, refresh token, token exchange, and the two that are retiring. People see that list and think they have a dozen things to learn.
I don’t want you to see it that way. Three quarters of these look almost identical. What changes is what’s passed at the entrance.
Passing something different
Section titled “Passing something different”You’ve now seen three flows in this chapter, and they’re one request with one card changed:
| The flow | grant_type | What’s presented at the entrance |
|---|---|---|
| Username-password (retiring) | password | A person’s username and password (module 2) |
| Client credentials | client_credentials | The app’s client ID and secret (module 3) |
| Refresh token | refresh_token | The re-entry pass (module 5) |
Same address, /services/oauth2/token. Same answer, an access token. Same second step, the stall. That flow is simple, and it’s going to be used for a whole bunch of flows, just substituting what’s presented.
Here’s the rest of the family, with what each one presents:
- JWT bearer presents a small signed token, a JWT, that names the user the app will act as, signed with the app’s certificate. That’s chapter 3’s signature at work. Chapter 11.
- SAML bearer assertion presents a signed SAML assertion, like chapter 6’s, from an identity provider the app trusts. Chapter 11.
- The device flow presents a device code, again and again, until a person approves it on another screen; then the answer is the wristband (chapter 5, module 5). Chapter 9.
- Token exchange presents a token from another identity provider, and swaps it for a Salesforce one. Chapter 11.
Each one is the same two steps. The client walks to the entrance, presents its proof, gets a wristband, and goes to the stall. Once you can read the base pattern, you can read every one of these. What you learn in each chapter is what’s presented, and why that proof can be trusted.
The one that’s different
Section titled “The one that’s different”There’s one flow that doesn’t fit the table, and it’s the most important one: the web server flow.
It isn’t a single step. Before the client ever walks to the entrance, a person has to sign in, in a browser, and say yes. That brings the browser back, with redirects, like single sign-on, and a short-lived code that the app then swaps for its tokens. It’s the most complicated flow, and the one Salesforce recommends whenever a person is using an app (module 2). It’s also where PKCE comes in.
That’s the flip. We built up the simple shape first; chapter 9 goes to the tougher one, at the Burger House. And here’s the thing: once you get the web server flow, the others really are smaller versions. Its last step, swapping the code for a token, is the base pattern you already know.
What you can do now
Section titled “What you can do now”At the end of this chapter, you can look at any token request and answer three questions:
- Where’s it going? Your My Domain’s
/services/oauth2/token. - What’s it presenting? The
grant_type, and the proof that goes with it. - Who will the wristband be for, and what will it allow? The user it runs as, and the app’s scopes.
That’s most of what an architect needs to read OAuth on the wire.
The end of the build-up
Section titled “The end of the build-up”Over eight chapters, you’ve seen people sign in to Salesforce directly (the Front Door), through an identity provider (chapters 4 and 6), and with Salesforce vouching for them (chapter 7). This chapter added the programs: a client at the entrance, with something to present.
Next comes the flip. Chapter 9 puts a person back in, through an app: the Burger House, the web server flow and PKCE.
What an architect decides here
Section titled “What an architect decides here”- For each integration, what it presents at the entrance, and whether that proof belongs in that system.
- Which flows your org allows at all, and which are blocked (the retiring ones first).
- Who reviews a new app’s flow, before it gets its client ID and secret.
Explore
Section titled “Explore”- OAuth Authorization Flows (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- OAuth Tokens and Scopes (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)