The Burger House
Module 1 of 5 in the chapter The Burger House: Flows With a Person, chapter 9 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: How does an app get a person’s Salesforce data without ever seeing her password?
The flip
Section titled “The flip”Chapter 8 built up the simple shape: a program walks to the entrance, presents something, and gets a wristband. Now we flip it. There’s a person in the picture again, and she isn’t the program.
Priya is at the Burger House, an app on its own web server. It makes the burgers: that’s its own data. But she wants a drink with her burger, and the Burger House doesn’t make drinks. Her drink is next door, at the food festival from chapter 8, where she has her own wristband account. The festival is Salesforce; the drink is her Salesforce data. Not anybody’s data: hers.
The Burger House wants to serve them together, its burger and her drink on one plate: its own data blended with hers. So it has to fetch her drink from the festival, for her.
How does it get it?
Two answers that don’t work
Section titled “Two answers that don’t work”Her password. The Burger House could ask Priya for her Salesforce username and password, and present them at the entrance. That’s chapter 8’s module 2, and it’s a no-no. Only Salesforce should have her Salesforce password. A password in another company’s system is one breach away from everybody’s problem.
An integration user. The Burger House could sign in as its own integration user, with client credentials. I always ask the room what that would mean. What could the Burger House see? Whatever the integration user can see. Who would show as the person who changed a record? The integration user. And if a hundred customers all go through the same integration user, they all see the same data. If this were a trading app, would you want one customer to see another customer’s money? You would not.
So the Burger House needs to act as Priya, with Priya’s access, and Priya must never give it her password. That’s the web server flow.
Five steps, three moves
Section titled “Five steps, three moves”- Priya orders a burger and her drink. The Burger House has the burger, but her drink is at the festival, in Salesforce. So it sends her browser to the festival’s entrance: Salesforce’s login page.
- She signs in at Salesforce, and only there, and approves: yes, the Burger House may fetch my drink. Salesforce sends her back, not with a wristband, but with a code: a claim ticket.
- Her browser brings the claim ticket to the Burger House.
- The Burger House swaps the ticket at the festival’s counter. It goes to Salesforce’s token endpoint itself, presents the code along with its own client ID and secret, and gets back her wristband, an access token, and a refresh token if it asked for one.
- It fetches her drink, her data, wearing her wristband, and serves the burger and the drink together: its data and hers on one page.
It looks like a lot. Really, it’s three moves: visit the login screen, come back with a code, swap the code for the tokens. And the last move is chapter 8’s base pattern again, with the code as the thing presented.
This is the most complicated flow there is. Learn this one, and all the others get simple.
Two channels
Section titled “Two channels”Look at where each thing travels. In my video I draw it in two colours, red and black.
The front channel is Priya’s browser: steps 1 to 3. Redirects, like single sign-on in chapter 4. The browser carries things from one place to another, and anything in a browser can be seen, by the person, by a browser extension, by something that shouldn’t be there. It’s a little less secure.
The back channel is server to server: steps 4 and 5. The Burger House calls Salesforce directly, over its own connection. Nothing passes through the browser.
That’s the design. What goes through the front channel is only the code: short-lived, and useless on its own. It never becomes the key; it’s only used for the exchange. The tokens, the things that actually grant access, come back on the back channel, and the browser never sees them.
The business license
Section titled “The business license”Why can’t anyone who sees the code swap it? Because the swap in step 4 needs something else: the Burger House’s own client ID and secret. Think of it as its business license. Salesforce knows the Burger House is allowed to act for its customers, and checks the license before it hands over anybody’s wristband.
That’s why Salesforce says this flow is for an app on a server “able to protect the external client app’s identity, defined by the client ID and client secret” (S1). The secret lives on the Burger House’s server, never in Priya’s browser.
There’s still a gap, though. In step 3, the code sits in her browser for a moment. Module 3 is about that moment.
The same flow, reversed
Section titled “The same flow, reversed”One more thing a student pointed out in class, and it’s worth carrying forward: this is exactly social sign-on, with the roles reversed. When you sign in to Salesforce “with Google”, Salesforce is the Burger House and Google is the entrance. Chapter 10 shows it.
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 person, through an app”, and the device flow from “Devices and things”.
Integration Architect tells the Burger House for integrations too, in its chapter 13, module 5, and walks it hands-on.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video of the Burger House, told with a beer garden; in the course, the drink comes from the food festival next door. It shows the front channel and the back channel the way I draw them. The note under the video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 2: on the wire, the three requests field by field.
What an architect decides here
Section titled “What an architect decides here”- Whether an app acts as a person or as its own user: her data and her name on the records, or one integration user for all.
- That the person signs in only at Salesforce, never in the app.
- Where the app’s secret lives: on its server, never in a browser.
Explore
Section titled “Explore”- OAuth 2.0 Web Server Flow for Web App Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)