Acting as Someone: The Impersonation Flows

Chapter 11 of Securing Salesforce: Identity and Access, Part 2: Accepting and Providing Identity. Start with chapter 9 if the Burger House and the web server flow are new to you.

In chapter 9, Priya was at the Burger House and signed in at Salesforce. Now she has a standing order. Every Friday night, the Burger House delivers her burger and her drink from the festival, whether she’s home or not. It has to fetch her drink as her, with her access and her name on every change, and nobody’s there to sign in.

That’s pure impersonation, done properly. This chapter is the flows that do it, and two more that carry identity in from somewhere else.

The ideas in this chapter

Nobody home: the integration user puts one name on every change, and a refresh token needs her to have signed in once. These flows need neither.
One step, no refresh token: present something signed, naming her, at the token endpoint, and get an access token.
The golden pass, JWT bearer: the Burger House’s certificate on the app, a JWT naming her, signed with its key. Powerful and dangerous: it can act as anyone the app pre-authorizes, so keep the list to a permission set with only those users.
Borrowed trust: when security won’t give one system the golden pass, let an identity provider both sides trust sign for her. The SAML bearer assertion is made by the client; the SAML assertion flow reuses the org’s single sign-on.
Token exchange: she’s signed in somewhere else; swap that identity provider’s token for a Salesforce one, and your handler decides who she is.
The asset token: a token for a thing, linked to an Asset record.

The picture

Here’s the chapter’s picture: chapter 9’s lanes, with nobody in Priya’s.

Click to enlarge

The path through this chapter

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

Nobody Home Two answers that don’t work; the empty lane; the trust comes first; three tools, one shape.
The Golden Pass An approved vendor; inside the envelope; on the wire; who it may act as; when to use it.
Borrowed Trust The security team said no; into Salesforce, the same way; two flows with almost the same name; choosing.
Token Exchange Signed in, somewhere else; the swap; the handler, chapter 10 again; on the wire; where it fits.
The Asset Token Things, not people; how a device gets one; not the device flow.

Then the practice: the golden pass by hand, from the certificate to a change recorded as Priya.

Check what stuck with the study guide.

Integration Architect names JWT bearer for integrations too, in its chapter 13, module 5.

What an architect decides here

Whether a change must carry a named person, or the integration user is fine.
Whether to create a new trust or borrow one: a golden pass, or an identity provider both sides trust.
Exactly who a system may act as: a permission set with only those users, never a profile, never an admin.
Where the private key lives, and who can reach it.
What a token exchange handler trusts, and whether it may create users.

Beyond the exam: what AI changes. An agent acting for Priya while she’s away is this chapter’s problem again: whose name is on the change, and who said it could act as her. Chapter 17 takes it further.

Explore

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

OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
Token Exchange Flow Diagram and Process (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)

Next: Getting Users In and Out: Provisioning.