Skip to content
SteveTechArcSteveTechArc Courses

The Decision Table

Module 6 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: Given any way into Salesforce, which door does it use?

Three questions, one table

Section titled “Three questions, one table”

Everything in this chapter comes down to three questions, asked in order.

  1. Who starts it? A person, a process, a device or a thing.
  2. What does it reach? Salesforce’s own pages, or its data through the API.
  3. With no person there, whose name does it run under? One integration user, or a chosen person.

Here they are as one table. Keep it beside you when you design, and when you review someone else’s design.

The table

Section titled “The table”
Who starts itWhat it reachesWhose nameThe doorTaught in
A person, in a browser (computer, phone or tablet)Salesforce’s own pagesThe personA direct login, or single sign-on through an identity provider. No OAuthChapters 2, 4, 6
A person, with a mobile appThe APIThe personOAuth web server flow with PKCE, with a refresh tokenChapters 8, 9, 13
A person, on another web server that reaches in for herThe API, for herThe personOAuth web server flow with PKCEChapters 8, 9
A person already signed in to a central identity provider, through apps and servicesThe APIThe personOAuth token exchange flowChapter 11
A process, with no person thereThe APIOne integration userOAuth client credentials flowChapters 8, 11
A process, with no person there, and a certificate preferredThe API, as a chosen personA chosen personOAuth JWT bearer flow (signed with a certificate; the app approved in advance)Chapter 11
A process, with no person there, through a trusted identity providerThe API, as a chosen personA chosen personOAuth SAML bearer assertion flowChapter 11
A device with little or no keyboard, and a person who approves itThe APIThe person who approvedOAuth device flow (local External Client Apps only, from 2026-11-30)This chapter, module 5; chapter 9
A connected thing, linked to an asset recordThe APIThe deviceOAuth asset token flowThis chapter, module 5; chapter 11
Who starts it, and what does it reach? Two columns. On the left, who starts it: a person in a browser, on a computer, a phone or a tablet; a person with a mobile app; a person on another web server that reaches into Salesforce for her; a process, as one integration user; a process, as a chosen person who isn't there; a device, which a person approves; and a connected thing, an asset in the org. An arrow from each says what it reaches and ends at its door. The person in a browser reaches Salesforce's own pages: log in, or single sign-on, with no OAuth, the only door without it. Everything else reaches the API with an OAuth flow: the mobile app and the other web server, the web server flow with PKCE; the integration user, the client credentials flow; the chosen person, the JWT bearer flow or the SAML bearer assertion flow; the device, the device flow; the connected thing, the asset token flow. Footnote: first ask who starts it, then ask what it reaches. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-IAM-CD-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} WHO STARTS IT THE DOOR A person in a browser on a computer, a phone or a tablet A person with a mobile app A person on another web server that reaches into Salesforce for her A process, as one integration user A process, as a chosen person who isn't there A device and a person approves it A connected thing an asset in the org Log in, or single sign-on no OAuth OAuth: web server flow with PKCE OAuth: web server flow with PKCE OAuth: client credentials flow OAuth: JWT bearer flow or the SAML bearer assertion flow OAuth: device flow OAuth: asset token flow Salesforce's own pages the API the API, for her the API the API, as her the API the API First ask who starts it. Then ask what it reaches. HOW TO READ IT the only door without OAuth © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Read it from the left. If a row matches, its door is your starting point, not your final answer. The rest of the design, which identity provider, which scopes, which policies, which user, follows in the chapters it names.

Every way in, on one grid

Section titled “Every way in, on one grid”

The table answers one question at a time. But it helps to see the whole course on one page, too. Here’s every way to sign in to Salesforce, or to sign in with Salesforce, that this course teaches, in nine sets. Each set is a row, named for who signs in and how. Each card is one mechanism, with the chapter that teaches it.

Every way to sign in, in sets A grid of every way to sign in, in nine sets, one per row, each mechanism with the chapter that teaches it. Logging in to Salesforce, where Salesforce checks who you are: username and password, chapter 2; multi-factor authentication, chapter 2; passwordless and headless, for customers, chapter 15. Single sign-on into Salesforce, where another system checks: SAML started at Salesforce, chapters 4 and 6; SAML started at the identity provider, chapter 6; OpenID Connect and social sign-on through an auth provider, chapter 10; delegated authentication, chapter 10. Salesforce as the identity provider: the SAML identity provider and Salesforce to Salesforce, chapter 7, and the OpenID Connect provider, chapters 7 and 9. A person through an app, OAuth with the person there: the web server flow with PKCE, chapters 5, 8 and 9; the refresh token flow, chapter 13; the token exchange flow, chapter 11; the user-agent flow, retiring 2027-02-20. A process as the integration user: the client credentials flow, chapters 5, 8 and 11; the username-password flow, retiring 2027-02-20, chapters 5 and 8; SOAP API login(), retiring Summer '27. A process as a chosen person: the JWT bearer flow and the SAML bearer assertion flow, chapters 5 and 11; the SAML assertion flow, chapter 11. Devices and things: the device flow, chapters 5 and 9; the asset token flow, chapters 5 and 11. Getting users in and out: just-in-time provisioning, the registration handler, and user provisioning to other apps, chapters 10 and 12. Agents: an agent as the logged-in user, a minimal agent user for customers, and identity across agent hops, chapter 17. Blue cards were met in Part 1, slate are taught later, amber are retiring. Footnote: every row ends at the same place, a session or an access token. {"author": "Steve Simpson", "blueprint": "1.2.1", "builder": "standard 1.59.0", "built": "2026-11-07", "id": "DGM-IAM-CD-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE SET: WHO SIGNS IN, AND HOW THE MECHANISMS Logging in to Salesforce Salesforce checks who you are Username and password the first factor · ch 2 Multi-factor authentication a second proof · ch 2 Passwordless and headless customers, your own screens · ch 15 Single sign-on into Salesforce another system checks who you are SAML, started at Salesforce SP-initiated · ch 4, 6 SAML, started at the IdP IdP-initiated · ch 6 OpenID Connect and social sign-on through an auth provider · ch 10 Delegated authentication Salesforce asks your system · ch 10 Salesforce as the identity provider other apps trust Salesforce SAML identity provider Salesforce signs the assertion · ch 7 OpenID Connect provider Salesforce as the login · ch 7, 9 Salesforce to Salesforce one org signs in to another · ch 7 A person, through an app OAuth, with the person there Web server flow with PKCE the one to learn · ch 5, 8, 9 Refresh token flow so she isn't asked again · ch 13 Token exchange flow from a central identity provider · ch 11 User-agent flow retiring 2027-02-20 · ch 9 A process, as the integration user OAuth, no person there Client credentials flow one user per integration · ch 5, 8, 11 Username-password flow retiring 2027-02-20 · ch 5, 8 SOAP API login() retiring Summer '27 · ch 13 A process, as a chosen person OAuth, acting for someone JWT bearer flow the golden pass · ch 5, 11 SAML bearer assertion flow an assertion from a trusted IdP · ch 5, 11 SAML assertion flow for orgs already on SAML · ch 11 Devices and things the device starts it Device flow a code on another screen · ch 5, 9 Asset token flow connected things · ch 5, 11 Getting users in and out provisioning Just-in-time provisioning a user made at first login · ch 12 Registration handler create user, update user · ch 10, 12 User provisioning to other apps and taking it away · ch 12 Agents AI acting for someone Agent as the logged-in user employee agents · ch 17 A minimal agent user customer agents · ch 17 Across agent hops on behalf of, and tools · ch 17 Every row ends at the same place: a session, or an access token. Retiring dates checked 2026-11-07. HOW TO READ IT met in Part 1 (chapters 2 to 5) taught in a later chapter retiring: still in orgs, not for new work © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The blue cards are the ones you’ve met in Part 1. The slate ones are still ahead, and the amber ones are on their way out. From here on, each chapter opens with its own row of this grid, on the map, so you always know where you are. And every row ends in the same place: a session, or an access token.

What’s leaving

Section titled “What’s leaving”

Some doors you’ll still find in orgs are closing. This is the second half of the table, and it’s dated, because it keeps changing. Check it again when you read this.

What you’ll findWhat’s happeningUse insteadSource
Username-password flow (the app sends a username and password)Blocked by default in orgs created since Summer ‘23; can’t be turned on in orgs created since Summer ‘26; retired for connected apps on 2027-02-20Client credentials (server to server); web server with PKCE (people)S1, S2
User-agent and hybrid user-agent flows (the token comes back to the browser)Blocked in orgs created in Winter ‘27; retired on 2027-02-20Web server (or hybrid web server) with PKCES3
Device flow on a connected app, a packaged app, or without a localhost callbackStops working on 2026-11-30A local External Client App with a localhost callbackS4
SOAP API login() (a username and password to the SOAP API)Retired in Summer ‘27, with steps before then from 2026-12-01OAuth: JWT bearer or client credentials for servers; web server for peopleS11
New connected appsCan’t be created without a request to Support since Spring ‘26; existing ones keep working, but reach end of support in Summer ‘27External Client AppsS12, S13

And one that isn’t retiring but has changed: since July 2026, PKCE is required for new apps that use the web server flow (S9).

How to use the table on a real project

Section titled “How to use the table on a real project”

When I start an identity design, I make a list of every way into the org. Every group of people, every app, every integration, every device. Then I take each one through the three questions and write down the row it lands on. Two things almost always come out of it.

  • It’s a blend. There’s never one answer for a whole company. Staff may use single sign-on, a partner its own identity provider, a mobile app the web server flow, and the nightly jobs client credentials.
  • Something is on the “leaving” list. There’s nearly always an old integration on a username and password somewhere. Find it before the date finds you.

Checkpoint 1, next, has you do exactly that for Steve Trucking.

What an architect decides here

Section titled “What an architect decides here”
  • The list of every way into the org, with its row in the table.
  • Each row’s door, and the reason, written down.
  • Everything on the “leaving” list, with an owner and a date to move it.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.