The Derivatives
Module 5 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: What happens when the person can’t type on the device, or when the app can’t keep a secret?
Once you get the big one
Section titled “Once you get the big one”Once you understand the web server flow, the others are derivatives: smaller versions of it. Here are two, one that’s growing and one that’s going.
The TV
Section titled “The TV”You’ve met the smart TV in chapter 5. You set up a streaming app on someone’s TV, and there’s no keyboard. So the TV shows a code, you type it on your phone, and a moment later the TV is signed in. That’s the device flow, for devices “with limited input or display capabilities, such as Smart TVs, appliances, and other IoT devices” (S7). Command-line tools use it too.
Here it is as a protocol.
1. The device asks for codes. It posts to the token endpoint with response_type=device_code and its client ID (S7). Only the client ID: a device can’t keep a secret either. Salesforce answers with three things and a number:
- a user code, “an 8-digit alphanumeric code”, short enough to read off a screen and type;
- a device code, which the device keeps, so this device and not another is the one that gets let in;
- the verification address, such as
https://MyDomainName.my.salesforce.com/setup/connect; - an interval, “the minimum number of seconds that we recommend waiting between polling requests”.
Both codes are “valid for 10 minutes” (S7).
2. The device shows the user code and the address. That’s the only thing that passes from the device to the person.
3. Priya signs in on her phone or laptop, at the verification address, types the code, and approves the device. Her password goes to Salesforce, and only Salesforce.
4. Meanwhile, the device keeps asking. Am I allowed in? Am I allowed in? It polls the token endpoint with grant_type=device and the device code, every interval (S7). Until she approves, the answer is “not yet”. Once she has, the answer is the wristband: Salesforce “sends an access and refresh token” (S7).
Look at step 4 and you’ll see chapter 8’s base pattern again: the same address, a grant_type, something presented. What’s presented is the device code, over and over, until it’s good.
One change to know about. Salesforce is narrowing who can use this flow. It’s now for “local external client apps with a localhost callback URL”; connected apps and packaged external client apps don’t qualify. From November 2026, “Salesforce blocks the device flow for all non-compliant apps” (S7), enforced November 30, 2026, and the flow is “intended only for apps that run on devices with limited input or display capabilities” (S8). The practice at the end of this chapter uses a compliant app.
The token in the browser
Section titled “The token in the browser”The other derivative is the one that’s going: the user-agent flow. It was built for apps that can’t keep a secret, like a mobile app or JavaScript in a browser. It “uses the OAuth 2.0 implicit grant type” (S9): no code, no swap. Salesforce sends the access token straight back to the browser, after a # on the end of the callback address (S9).
Put it next to the Burger House and you see the problem. The web server flow went to all that trouble to keep the token off the front channel: only a short-lived code passes through the browser. The user-agent flow puts the wristband itself in the address bar. Salesforce’s warning: “Because the access token is encoded into the redirection URL, it can be exposed to the user and other apps on the device” (S9).
That’s why it’s retiring. In the release update’s words, the user-agent and hybrid user-agent flows “are insecure because they directly expose access tokens to the browser”, and Salesforce enforces their retirement on February 20, 2027. They’re already blocked in orgs created in Winter ‘27, and “Integrations that use these insecure flows will no longer work when the retirement takes effect” (S10).
What replaces it is the flow from module 3. For a mobile app, a web server flow with PKCE: PKCE was built for exactly the apps that can’t keep a secret, and once the web server flow had its weakness fixed, that’s where these apps went. Salesforce names it, or the hybrid web server flow, with PKCE (S10, S1).
Check your mobile apps
Section titled “Check your mobile apps”One more thing, said fairly. The user-agent flow’s own Help page still carries this warning: “Many mobile apps, including Salesforce mobile apps, use the user-agent flow and, blocking the user-agent flow will break those apps” (S9). The release update says integrations on it will stop working in February 2027 (S10). Both are Salesforce’s own words, and the practical meaning is the same: before that date, find every app in your org that uses this flow, your own and the ones you install, and know what each one will use instead. For apps you didn’t write, Salesforce’s advice is to contact the developer (S10). For Salesforce’s own apps, watch the release notes (chapter 7’s research: Salesforce is moving its own apps off connected apps).
The end of the flip
Section titled “The end of the flip”That’s the flip. A person through an app: the web server flow, made safe by PKCE, made to say who she is by OpenID Connect, and two derivatives, the device that shows a code and the browser that used to hold the token. Next, chapter 10 turns the Burger House around: social sign-on, with Salesforce as the app.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video of the device flow, with a demo: the codes, the verification page, the polling. The practice at the end of this chapter does the same, on today’s external client apps. The note under the video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”The practice: the device flow, hands-on.
What an architect decides here
Section titled “What an architect decides here”- Which devices or tools need the device flow, and that each uses a local external client app with a localhost callback.
- Which apps in the org still use the user-agent flow, and what each moves to before February 20, 2027.
- Whether to block the retiring flows now, once every app has moved.
Explore
Section titled “Explore”- OAuth 2.0 Device Flow for IoT Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- OAuth 2.0 User-Agent Flow for Desktop or Mobile App Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- OAuth User-Agent and Hybrid User-Agent Flows Retirement (Release Update) (opens in a new tab) (Salesforce Winter ‘27 release notes; checked 2026-11-07)