Skip to content
SteveTechArcSteveTechArc Courses

Don't Go Straight to the Stall

Module 1 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: Why can’t a client just go to the API and ask, and what are the parts of every OAuth exchange?

Back to the food festival

Section titled “Back to the food festival”

You’ve met the food festival before, in the Front Door chapter. There are dozens of stalls, and the people cooking don’t want to take your money or check who you are. They just want to serve, quickly. So that’s done somewhere else: at the entrance. You show who you are, and you get a wristband. Then you go to any stall, show the wristband, and they serve you. The stall never sees your ID. It just checks the wristband.

That’s OAuth. And the first rule is the one in the title: you don’t go straight to the stall. Walk up to a stall without a wristband, and they send you to the entrance.

This chapter is what happens at that entrance, in detail. Not the story this time, but the protocol underneath it: who’s who, what’s sent, what comes back. Once you can read that, every flow in the next three chapters is easier.

The four roles

Section titled “The four roles”

Every OAuth exchange has the same four parts. In class I give them their real names, because they’re on the test and in every document you’ll read.

  • The resource owner owns the data. Usually that’s a person, or the company that set up what’s allowed. Think of the resource owner as the one who set up the ground rules.
  • The client is the software that wants the data: a phone app, another server, an integration, an agent. Not a person. A program.
  • The authorization server is the entrance. In Salesforce, it’s the token endpoint on your My Domain. It checks what the client presents and gives out the token.
  • The resource server is the stall: the API that holds the data, Salesforce’s REST API, Bulk API and the rest.

If that sounds familiar, it should. It’s the same triangle as single sign-on: the client, the auth server, the resource server. The auth server is the same guard you met in the Front Door chapter, the one who checks who you are before anyone gets in. What’s different is who does the walking.

No browser carrying messages

Section titled “No browser carrying messages”

In single sign-on, the browser carries everything. The identity provider and Salesforce never call each other; the browser is redirected from one to the other, carrying the request and the response (chapter 4).

In the flows in this chapter, there are no redirects. The client has to know to do it itself. It uses its own feet, so to speak: it walks over to the auth server, presents something, and gets back a token. Then it walks over to the resource server and shows the token. Two direct calls, from the client, and no browser in between.

That’s why the shape is so simple.

Two steps

Section titled “Two steps”
Don't go straight to the stall: the base pattern Three columns: the client, the entrance, Salesforce's token endpoint, and the stall, an API. Step 1: the client goes to the entrance and presents something, with a POST to /services/oauth2/token; the entrance checks what's presented and gives back the wristband, an access token. Step 2: the client goes to the stall and shows the wristband, a Bearer token, on every call; the stall checks the wristband, never the client's ID, and sends back the data. Footnote: two steps, always the same; what changes from flow to flow is what's presented at the entrance. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-IAM-OF-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE CLIENT THE ENTRANCE: SALESFORCE'S TOKEN ENDPOINT THE STALL: AN API 1. Goes to the entrance POST /services/oauth2/token, with something to present The entrance checks what's presented; gives out a wristband 2. Goes to the stall shows the wristband on every call The stall checks the wristband, never your ID presents something the wristband the wristband the data Two steps, always the same. What changes from flow to flow is what's presented at the entrance. HOW TO READ IT the entrance: where you prove who you are, once © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge
  1. The entrance. The client sends a request to Salesforce’s token endpoint, /services/oauth2/token, on your My Domain. In it is something that proves who the client is, or who it’s acting for. If the entrance accepts it, it answers with an access token: the wristband.
  2. The stall. The client calls the API and shows the access token on every call, in the request’s Authorization header as a Bearer token (S2). The API checks the token and serves the data.

It’s a two-step process: go to the entrance, get the wristband; go to the stall, get what you came for.

And here’s the part to hold on to for the whole chapter. Every single-step flow sends its request to the same address, /services/oauth2/token (S1, S3, S6). What changes from one flow to the next is only what the client presents at the entrance. A person’s password, once. The program’s own key and secret, today. A re-entry pass, a signed token, an assertion. The picture above stays the same all chapter; only one card changes.

Why bother with an entrance?

Section titled “Why bother with an entrance?”

Why not let the client send a password to the API on every call, and be done with it?

Because the goal of OAuth is to keep credentials from being passed around. A password should go to one place only: the system that checks it. Not to every app that wants the data, and not on every call. The entrance checks the proof once and swaps it for a wristband, and the wristband is what travels.

That buys three things:

  • The stalls never see a password. They only check wristbands, so a stall that’s careless with what it’s given can’t leak a password it never had.
  • A wristband doesn’t last. An access token lives “usually minutes or hours” (S2). A stolen one stops working when it runs out. A stolen password works until someone changes it.
  • A wristband can say what it’s for. It can be limited to some kinds of access and not others: the scopes, in module 4.

One caution, from the Front Door chapter: while it’s valid, the wristband is the access. The stall checks the wristband, not your face. Whoever holds a valid token gets served. That’s why tokens are what attackers go looking for, and why the rest of this course keeps asking how long a token lives and how you take it back.

On the map

Section titled “On the map”

On the grid of every way to sign in (chapter 5, module 6), this chapter is the row “A process, as the integration user”, plus the shape every single-step flow shares.

On the map: a process, as the integration user On the map: the set A process, as the integration user, OAuth with no person there. Client credentials flow, one user per integration, chapters 5, 8 and 11, in blue; username-password flow, retiring 2027-02-20, chapters 5 and 8, in amber; SOAP API login(), retiring Summer '27, chapter 13, in amber. {"author": "Steve Simpson", "blueprint": "1.1.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-IAM-OF-07", "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 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 HOW TO READ IT taught so far (chapters 2 to 8) retiring: still in orgs, not for new work © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Watch it on video

Section titled “Watch it on video”

In 2023 I made a video of this base pattern, told at a beer garden: the entrance, the wristband and the stall. The course tells it at a food festival, and the video uses the username-password flow that module 2 retires. The note under the video says what’s still right and what’s changed since.

STA 3.10 · Tap into Salesforce Security: Navigating OAuth Flows with a Beer Garden Analogy · 6:50 · published 2023-10-02 · plays from YouTube when you click it · Watch on YouTube · More videos: Salesforce Identity & Access Videos

What’s next

Section titled “What’s next”

Module 2: how it began, with a person’s password at the entrance.

What an architect decides here

Section titled “What an architect decides here”
  • Which role each system plays in an integration: who’s the client, who’s the resource owner, and whose rules apply.
  • That no client goes straight to the stall: every program gets its token at the entrance, on your My Domain.
  • How long a wristband should live, and what you’ll do when one is stolen (chapter 13).

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.