Who Starts It, and What Does It Reach?
Module 1 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: Single sign-on and OAuth both get someone into Salesforce. So how do you know which one a situation needs?
Two words that sound the same
Section titled “Two words that sound the same”There are two terms you’ll hear in every identity conversation: single sign-on and OAuth. And it’s hard to know when to use which. Both of them “log you in”. Both of them involve a token, a redirect, and some trust set up in advance. So people use them as if they were the same thing, or as if they were rivals and you had to pick a favorite.
They aren’t rivals. They answer different situations. Once you can see the situation clearly, the choice almost makes itself. And you can see it with two questions.
Question one: who starts it?
Section titled “Question one: who starts it?”Every time something gets into Salesforce, something starts it. There are really only three kinds of starter.
- A person. Priya sits down, opens her browser or picks up her phone, and goes to work. So it all begins with the human.
- A process. A program on a server, with no one at the keyboard: a nightly load, an export, a middleware server reaching in at two in the morning. When I say “client” here, I don’t mean a customer. I mean a program, the client in client and server.
- A device. A smart TV, an appliance, a sensor in a warehouse. It starts the conversation itself, and sometimes it needs a person to say yes.
Question two: what does it reach?
Section titled “Question two: what does it reach?”The second question is where it’s going. There are two places to reach in Salesforce.
- Salesforce’s own pages. Priya’s browser shows her Lightning pages, her records, her reports, drawn by Salesforce.
- Salesforce’s data, through the API. Something else draws the screen, or there’s no screen at all. A mobile app, another web server, a nightly job: they ask Salesforce’s API for the data and do something with it.
Put those two questions together and you have the whole chapter. Only one combination goes without OAuth: a person in a browser, reaching Salesforce’s own pages. That person logs in, either directly with a Salesforce username and password, or through single sign-on, with an identity provider in charge of the login (chapter 4). Everything that reaches the API uses OAuth: an open standard for giving an app limited access to Salesforce, through a token, without handing it a password.
Both roads lead to the same place
Section titled “Both roads lead to the same place”Here’s a picture I like to show before any of the detail. On one side, a person with a browser. On the other side, a client application: a mobile app, a server, any of a number of systems that want the data. Either side first reaches up to the authentication server, the security guard from the front door (chapter 2). Either side can be filtered there: TLS, multi-factor authentication, IP restrictions, a client certificate.
And it all leads to the session token. The browser gets a session for Salesforce’s pages; the client app gets an access token for the API, which is a session by another name. After that, authorization takes over: what can this person, or this program acting as someone, see and do?
So the difference between single sign-on and OAuth isn’t the destination. It’s the road there, and that depends on who’s driving and what they want to reach.
The third question, when no one’s there
Section titled “The third question, when no one’s there”When a person starts it, the work runs under that person’s name. Priya’s changes say Priya.
When a process starts it, you have to decide whose name it runs under. That’s the third question, and it’s one of the two decision makers I always come back to: am I designating a person, or am I using an integration user?
- An integration user: one user record set up for the integration itself. Every change it makes says “Integration User”.
- A chosen person: the process acts as Priya, with Priya’s access, even though Priya isn’t there.
Each answer leads to a different OAuth flow, and module 4 takes them one at a time.
The map
Section titled “The map”Here’s the map, with the starters on the left, what each one reaches on the arrow, and the door on the right. The top three rows begin with a person. The rest begin with a process, a device or a thing.
An OAuth flow is one recipe for getting the token: who asks, what they present, and what they get back. Salesforce supports a number of them, and each one fits a different row (S1). You don’t need to know their steps yet. Chapters 8 to 11 teach them. You need to know which row you’re in. And module 6 puts every one of them, with every way to sign in that this course teaches, on one grid.
Why the map comes first
Section titled “Why the map comes first”Why spend a whole chapter on choosing, before learning a single flow? Because I’ve seen the other way round. A team learns one flow, likes it, and uses it for everything. Or someone reads that single sign-on is “more secure” and tries to use it for a nightly integration, which has no browser to redirect and no person to sign in.
The mechanism follows the situation. Ask who starts it and what it reaches, and you’ll be right before you’ve opened Setup.
Watch it on video
Section titled “Watch it on video”Two of my 2023 videos go with this module: when to use single sign-on and when OAuth, and the words of OAuth, told at a beer garden. The note under each video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 2 takes the top row: a person in a browser, and the moment the identity provider makes it single sign-on.
What an architect decides here
Section titled “What an architect decides here”- For every way into the org: who starts it, a person, a process or a device.
- What it reaches: Salesforce’s own pages, or the data through the API.
- For every process: whose name it runs under, an integration user or a chosen person.
- And only then, which door: a login, single sign-on, or an OAuth flow.
Explore
Section titled “Explore”- OAuth Authorization Flows (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)