The Asset Token
Module 5 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 does a connected device get a token of its own, tied to what it is?
Things, not people
Section titled “Things, not people”Every flow so far has been about a person: Priya signing in, or a system acting as her. This one is about a thing.
Say a customer buys a printer that’s connected to the internet. Once it’s set up, it runs on its own, reporting its state, its errors, and when it’s low on toner, to the company’s backend service. Nobody’s at the keyboard. And the backend needs to know: which printer is this, exactly? Which customer does it belong to?
That’s an obscure one, honestly. It might be a single question on an exam. But it’s worth knowing, because it uses something you’ll recognize from Service Cloud: the Asset object. In Salesforce’s words, asset tokens “identify the device to a backend service” and link it “to Salesforce CRM data about the customer, account, or contact” (S7). An asset token is a JWT, “an open-standards-based JWT authentication token for verifying and securing requests from connected devices” (S7).
How a device gets one
Section titled “How a device gets one”Salesforce’s example is that printer (S7). The customer has an account on the company’s support site, and the company has a mobile app that registers devices.
- The app gets an access token for the customer, with an ordinary OAuth flow. Salesforce mentions the web server flow and JWT bearer as common ways (S7).
- The app swaps it for an asset token. It sends the access token, plus an actor token describing the device, to the token endpoint, using the token exchange protocol from module 4 (S7). The actor token can carry the device’s ID and details of the Asset: an existing one, or a new one.
- Salesforce registers the device. It issues the asset token, links the device to an Asset record, and “publishes an asset token event” (S7).
- The device runs on its own, sending its data with the asset token. If the backend sees something wrong, it can open a case on the asset, which is tied to the customer’s contact and the support process (S7).
The external client app has to be set up to issue asset tokens first (S7).
Not the device flow
Section titled “Not the device flow”Don’t mix this up with chapter 9’s device flow. They sound alike, and they answer different questions.
- The device flow is a person, through a device: a TV or a command-line tool with no keyboard to speak of. Priya types a code on another screen, and the device acts as her.
- The asset token is the device as itself: which printer it is, and which Asset it belongs to. A person helped register it once, through the app. After that, the token is about the thing.
On the map
Section titled “On the map”On the grid of every way to sign in (chapter 5, module 6), the asset token sits in the row “Devices and things”, beside the device flow. That’s the last card in this chapter’s rows.
Test knowledge. In my experience, know that the asset token flow is for connected devices, and that it links the device to an Asset record in Salesforce.
What’s next
Section titled “What’s next”That’s the chapter. The practice builds module 2’s golden pass by hand. Then chapter 12: Getting Users In and Out, with just-in-time provisioning and the registration handler side by side.
What an architect decides here
Section titled “What an architect decides here”- Whether a device needs its own identity, or acts for a person (the device flow).
- How devices are registered, and by which app.
- Which Asset and account each device is tied to.
Explore
Section titled “Explore”- OAuth 2.0 Asset Token Flow for Securing Connected Devices (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)