SSO or OAuth? Choosing the Mechanism

Chapter 5 of Securing Salesforce: Identity and Access, Part 1: Who Are You? The last chapter of Part 1. New to the course? Start with chapter 1.

Here’s the question for this chapter. Single sign-on and OAuth both get someone into Salesforce. Both use a token, a redirect, and some trust set up in advance. So how do you know which one a situation needs?

Chapter 4 showed what single sign-on is: one identity provider, and a browser that carries every message. This chapter steps back before any flow is taught step by step, and chooses the door. It takes two questions, and a third when nobody’s there.

The ideas in this chapter

Two questions choose the door. Who starts it: a person, a process or a device? And what does it reach: Salesforce’s own pages, or its data through the API?
A third question when no one’s there: whose name does the work run under, one integration user or a chosen person?
Log in, single sign-on and OAuth are three answers, not three rivals. Every road ends at the same place: a session, or an access token.
Only arrows from the browser means single sign-on. A person in a browser on Salesforce’s own pages logs in or uses single sign-on, and never needs OAuth.
One system calling another needs OAuth. The little line from an app or another server to Salesforce’s API. With the person there, it’s the web server flow with PKCE.
Never hand an app a password. OAuth gives it a limited, revocable token instead. The user-agent and username-password flows are retiring on 2027-02-20.
First ask: should we just use the integration user? One user per integration, on the client credentials flow, and every change says so.
Acting as a named person takes much more trust. JWT bearer is the golden pass, “very powerful, and dangerous”; the SAML bearer assertion uses an identity provider you already trust.
Devices start it themselves. The device flow, with a person approving a code on another screen; the asset token flow for connected things.
One table, one grid. The decision table chooses the door; the master grid shows every way to sign in that the course teaches, and each later chapter shows its own row.

The picture

Here’s the map the chapter turns on: who starts it on the left, what it reaches on the arrow, and the door on the right.

Click to enlarge

Only one row goes without OAuth: a person in a browser, on Salesforce’s own pages. Everything else reaches the API. The mechanism follows the situation, and you can be right before you’ve opened Setup.

The path through this chapter

Seven modules, each standing on its own.

Who Starts It, and What Does It Reach? Two words that sound the same; the two questions; both roads lead to the session token; the third question when no one’s there; the map.
A Person in a Browser: Log In, or Single Sign-On The whiteboard: browser to system A, browser to Salesforce, then the identity provider; only arrows from the browser; why there’s no OAuth in this row.
A Person Through an App or Another Server: OAuth The little line; why not give it her password; the web server flow with PKCE; the user-agent flow, retiring; the refresh token; the token exchange flow.
No Person There: The Integration User, or a Chosen Person When the browser goes away; client credentials and one user per integration; JWT bearer, the golden pass; the SAML bearer assertion, and a story about SAP; the question to ask.
Devices and Things The smart TV and the device flow, tightened in 2026; connected things and the asset token flow.
The Decision Table Three questions, one table; every way in, on one grid; what’s leaving, with its dates; how to use it on a real project.
Checkpoint 1: Steve Trucking Six groups that sign in, the lines, and a door for each. It’s usually a blend.

The order follows the map, top to bottom: the person in a browser, the person through an app, the process with no one there, and the devices. Then the whole map in one table, and a real company to try it on.

Check what stuck with the study guide.

What an architect decides here

Every way into the org, listed: every group of people, every app, every integration, every device.
For each one: who starts it, and what it reaches.
For every process: whose name it runs under, an integration user or a chosen person, with the reason written down.
The door for each, from the decision table: a login, single sign-on, or an OAuth flow.
No passwords handed to apps, and no new work on the user-agent or username-password flows.
For acting as a person: JWT bearer or the SAML bearer assertion, and which users can be named.
Everything on the “leaving” list, with an owner and a date to move it.

Beyond the exam: what AI changes. An agent acting for Priya is a process acting as a chosen person: the second half of the map, where the person isn’t there. So the same questions apply, and they matter more. Whose name does the agent run under? Who said it could? How much can it do as her? The token exchange flow is one way a person’s identity is passed along between services. Chapter 17 takes the questions all the way through, for agents.

Explore

Each module lists its own sources, each checked 2026-11-07. Two to start with:

OAuth Authorization Flows (opens in a new tab), Salesforce Help (Winter ‘27; checked 2026-11-07)
Give Integration Users API Only Access (opens in a new tab), Salesforce Help (Winter ‘27; checked 2026-11-07)

Next: Salesforce as the Service Provider: SAML, the start of Part 2.