Nobody Home
Module 1 of 5 in the chapter Acting as Someone: The Impersonation Flows, chapter 11 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: How can a system act as a named person when she isn’t there to sign in?
The Burger House, with nobody home
Section titled “The Burger House, with nobody home”In chapter 9, Priya ordered at the Burger House, and the Burger House fetched her drink from the festival next door. She was there: she signed in at Salesforce, and the Burger House got a code and swapped it.
Now say Priya has a standing order. Every Friday night, the Burger House delivers her burger and her drink, whether she’s home or not. She might be asleep. She might be away. The Burger House still has to fetch her drink, as her, with nobody there to sign in.
Out of the story: a system needs to act as a named person, with her access and her name on every change, when she isn’t there. A nightly job that updates records as the person who owns them. Another company’s system pushing changes into Salesforce, each one recorded as the user who made it there. That’s what this chapter is about. It’s pure impersonation, done properly.
Two answers that don’t work
Section titled “Two answers that don’t work”The integration user. Chapter 8’s client credentials flow: the Burger House signs in as its own user. What could it see? Whatever the integration user sees. And who shows as the person who changed the record? The integration user. Every change, every customer, one name. If the requirement says each change must carry the person who made it, the integration user can’t do it.
A refresh token from last week. Chapter 9’s web server flow could work, once: Priya signs in, approves, and the Burger House keeps a refresh token to use on Friday nights. But she’d have had to sign in at least once, and keep it alive. And there are cases where you never need the person at all: she may never sign in to the Burger House. You still want to act for her.
So we need something else: a way for a trusted system to say “let me in as Priya” without Priya, and without her password.
The empty lane
Section titled “The empty lane”Here’s chapter 9’s picture again, in the same places. Look at the first lane.
Notice there’s nobody in Priya’s lane. And nobody goes to Salesforce’s login page. The browser, the redirects, the code: all of chapter 9’s front channel is gone.
What’s left is chapter 8’s base pattern, with one difference. The Burger House walks to the token endpoint and presents something. But what it presents isn’t its own client ID and secret. It’s something signed, that names Priya. Salesforce checks the signature, checks who it names, and hands back an access token for Priya. Then the Burger House fetches her drink, as her: her access, and her name on every change.
That’s it. One step again.
The trust comes first
Section titled “The trust comes first”Why would Salesforce believe a message that just says “let me in as Priya”?
Think back to single sign-on. What did the identity provider and Salesforce have to do before Salesforce would believe an assertion? They set up trust, with a certificate: Salesforce knew the identity provider’s signature (chapters 3 and 6). Then a signed assertion was enough. Nobody asked the person again.
These flows work the same way. The trust is set up once, before anything happens, and Salesforce says which people the Burger House may act as. In Salesforce’s words, the flow “doesn’t require explicit user interaction. However, this flow does require prior approval” (S1). After that, a signed message is enough.
Three tools, one shape
Section titled “Three tools, one shape”Salesforce has three flows with this shape:
- The JWT bearer flow. The Burger House has its own certificate on the app in Salesforce, and signs a small token naming Priya. The tightest trust there is. Module 2.
- The SAML bearer assertion flow. The same idea, with a SAML assertion instead of a JWT. Module 3.
- The SAML assertion flow. No certificate of the Burger House’s own: it presents an assertion from the identity provider Salesforce already trusts for single sign-on. Borrowed trust. Module 3.
All three are one step at the token endpoint. And all three give back an access token and never a refresh token (S1, S3, S4). Why would they? A refresh token is for coming back without asking the person again. Here there’s no person to ask. When the access token runs out, the Burger House just presents a new signed message.
Salesforce’s own example is a report service that runs every night: it sends its JWT, gets a token, pulls the data and builds the report, with nobody awake (S1).
Two more flows in this chapter work differently. Token exchange is for when Priya is signed in, just somewhere else, and an app holds her token from another identity provider (module 4). And the asset token is for things, not people (module 5).
On the map
Section titled “On the map”On the grid of every way to sign in (chapter 5, module 6), this is the row “A process, as a chosen person”: JWT bearer and the SAML bearer assertion flow, with the SAML assertion flow beside them. Chapter 5 put them on the map. This chapter takes them apart.
Test knowledge. In my experience, know when you need these flows: a system acting as a named user, with no person there to sign in, and no refresh token issued.
What’s next
Section titled “What’s next”Module 2: the golden pass. The JWT bearer flow.
What an architect decides here
Section titled “What an architect decides here”- Whether a change must carry a named person, or whether the integration user is fine.
- Whether a person is ever there to sign in, and so whether the web server flow could do it.
- Which system is trusted enough to act as someone, and for whom.
Explore
Section titled “Explore”- OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)