The Burger House: Flows With a Person

Chapter 9 of Securing Salesforce: Identity and Access, Part 2: Accepting and Providing Identity. Start with chapter 8 if the food festival and the wristband are new to you.

Chapter 8 built up the simple shape: a program walks to the entrance, presents something, and gets a wristband. This chapter is the flip. 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 server. It makes the burgers. But her drink is next door, at the food festival, Salesforce, where she has her own account. The Burger House wants to serve them together, so it has to fetch her drink for her, without ever seeing her password. That’s the web server flow, the most complicated flow there is. Learn it, and all the others get simple.

The ideas in this chapter

Not her password, and not the integration user: the app has to act as her, with her access.
Three moves: she signs in at Salesforce and only there, comes back with a code, and the app swaps the code for tokens, server to server.
Two channels: the browser carries only a short-lived code; the tokens travel server to server.
Two trips to Salesforce: the authorize request through the browser, and the token request from the server, which is chapter 8’s base pattern again.
The pickup word, PKCE: the app sends a fingerprint first and shows the word at the swap, so a stolen code gets nothing. Required for new apps since July 2026.
OpenID Connect is the same flow plus openid: an ID token says who signed in, not only what the app may reach.
The device flow: a code on one screen, approval on another, and polling until it’s allowed in.
The user-agent flow put the token in the browser, and retires on February 20, 2027.

The picture

Here’s the chapter’s picture. It stays the same in modules 1, 3 and 4; only what rides on the arrows changes.

Click to enlarge

The path through this chapter

Five modules, each standing on its own, and a practice.

The Burger House The flip; two answers that don’t work; five steps, three moves; two channels; the business license; the same flow, reversed.
On the Wire Two trips to Salesforce; the authorize request; the callback; the token request; the answer; when it goes wrong.
The Pickup Word The weakness; the pickup word; on the wire; why a fingerprint works; not optional any more.
Who Is She? Access isn’t identity; the same flow, plus openid; the ID token; Salesforce as the login for another app; the mirror.
The Derivatives The TV; the token in the browser; check your mobile apps.

Then the practice: the device flow, hands-on, and the web server flow read off the wire.

Check what stuck with the study guide.

Integration Architect tells the Burger House for integrations too, in its chapter 13, module 5, and walks the web server flow hands-on.

What an architect decides here

Whether an app acts as a person or as its own user.
That the person signs in only at Salesforce, and the app’s secret stays on its server.
The callback URLs and scopes on each app, exact and narrow.
PKCE on every app that uses the web server flow, and when to require it for the whole org.
Identity, access, or both: openid for who, the API scopes for what.
Which devices need the device flow, each on a local external client app.
Which apps still use the user-agent flow, and what each moves to before February 20, 2027.

Beyond the exam: what AI changes. An agent acting for Priya through an app is the Burger House again: it should get her wristband through this flow, with her approval, not her password, and only the scopes it needs. Chapter 17 takes it further.

Explore

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

OAuth 2.0 Web Server Flow for Web App Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
OAuth 2.0 Device Flow for IoT Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)

Next: The Mirror Image: Social Sign-On and Delegated Authentication.