The Integration User, or a Chosen Person
Module 4 of 7 in the chapter SSO or OAuth? Choosing the Mechanism, chapter 5 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: When a process reaches Salesforce with no one at the keyboard, whose name does it run under, and which flow follows from that?
When the browser goes away
Section titled “When the browser goes away”Back to the whiteboard one last time. System A, Salesforce, the identity provider, and Priya’s browser. In module 3, system A called Salesforce for Priya, with Priya there to log in and approve.
Now take the browser away. It’s two in the morning. Nobody’s at the keyboard. System A still needs to reach Salesforce: a nightly load, an export, a middleware server moving orders.
There’s no one to show a login page to, so no redirect, no single sign-on, and no web server flow. It’s OAuth, and the first thing to decide is whose name the work runs under.
First ask: should we just use the integration user?
Section titled “First ask: should we just use the integration user?”That’s always my first question. If all you’re going to do is share one user for this integration, the answer is simple.
An integration user is a Salesforce user set up for one integration, not for a person. Salesforce’s own advice is one user for every integration, so each one gets only the data it needs, and you can trace what each one did (S8). The Salesforce Integration user license exists for this: its Minimum Access - API Only Integrations profile lets the user work only through the API (S8).
The flow is the client credentials flow. The app exchanges its own credentials, a consumer key and a consumer secret, for an access token, and Salesforce runs everything as the integration user you assigned (S5). No person, no redirect, no refresh token.
Two things follow from that choice.
- Every change says “Integration User”. All your sharing and record access is the integration user’s, and Last Modified By and Created By are the integration user, not the person the change was for.
- The secret is the key to the door. Salesforce warns that “any person or app that has access to your external client app’s consumer key and consumer secret can get an access token” (S5). Keep it in a vault and change it regularly.
There’s also an old way you’ll still find: the username-password flow, where the app sends the integration user’s username and password. You shouldn’t use it, but you should know it’s there. It’s blocked by default in orgs created since Summer ‘23, and Salesforce retires it for connected apps on February 20, 2027 (S1, S2). For server-to-server work, its replacement is client credentials (S2).
When it has to be a specific person
Section titled “When it has to be a specific person”Sometimes the integration user isn’t enough. The requirement says the change must be made as Priya: her access, her name on the record. But Priya isn’t around. We just need system A going to Salesforce, but we want to go as Priya.
That needs a much stronger trust, and there are two ways to build it.
JWT bearer: the golden pass
Section titled “JWT bearer: the golden pass”Remember how single sign-on built its trust? A digital certificate, installed in advance. The JWT bearer flow does the same thing. System A holds a private key, and its certificate is installed in Salesforce. System A writes a short message, a JWT (JSON Web Token), that says, in effect, “let them in as Priya”, signs it, and sends it to Salesforce. Salesforce checks the signature against the certificate and issues an access token as Priya, at once (S6).
It’s like a golden pass. You hand it over, it’s been properly stamped, and inside it says who to let in. No human involvement. So this is very powerful, and dangerous. Salesforce does require the app to be approved in advance: with Admin approved users are pre-authorized, only the users whose profiles and permission sets you allow can be named in the pass (S6). Within that group, system A can become anyone.
So you set it up only when the two systems are very trusted: both are your company’s own systems, and you’d trust system A with anyone’s identity.
The SAML bearer assertion: when security says no
Section titled “The SAML bearer assertion: when security says no”Here’s a story from a project I worked on. The two systems were Salesforce and SAP, and every request into SAP had to go as a specific user. JWT would have meant that Salesforce could go into SAP and pretend to be anyone. Do you think that made the security people happy? It didn’t.
But they did have a single sign-on identity provider that both sides already trusted. So the middleware asked the identity provider for a SAML assertion for that one user, and presented the assertion to SAP. The platform event that started it carried only the username. No passwords: a password in every event would have been in reach of anyone who could read the events.
The pattern is the point. If you can’t give a system the power to be anyone, look for an identity provider that’s already trusted, and present an assertion instead, the same signed statement single sign-on uses. In Salesforce, that’s the SAML bearer assertion flow: the app posts a signed SAML assertion, and Salesforce checks the signature against the certificate registered for the app, and “the audience, issuer, subject, and validity of the assertion” (S7). Those are the same checks from chapter 4, module 6.
Salesforce also has a SAML assertion flow, a different thing, for orgs already using SAML single sign-on that want to reach the API the same way (S1). The names are close. Chapter 11 sorts them out.
The question to ask
Section titled “The question to ask”So if you ever hear a requirement to use a specific user, and there’s no person directly involved, stop and ask why. Often the integration user is enough. If it truly has to be a person, you can set up the tightest one possible, JWT bearer, or you can ask: do you have an identity provider around, and can I get an assertion from it?
On the map
Section titled “On the map”On the grid of every way to sign in (module 6), this module is two sets: a process as the integration user, and a process as a chosen person. Two of the integration user’s doors are closing; see module 6 for the dates.
Watch it on video
Section titled “Watch it on video”Two of my 2023 videos go with this module: the JWT bearer flow, and the two SAML flows with nearly the same name. The note under each video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 5: devices and things, where the device starts it and a person, sometimes, approves.
What an architect decides here
Section titled “What an architect decides here”- Integration user or a chosen person, for every process, with the reason written down.
- One integration user per integration, on the Salesforce Integration license where it fits, with only the access it needs.
- Where the consumer secret lives, and how often it changes.
- For acting as a person: JWT bearer or the SAML bearer assertion, which users can be named, and which systems are trusted that much.
- Every username-password integration found and moved before February 20, 2027.
Explore
Section titled “Explore”- OAuth 2.0 Client Credentials Flow for Server-to-Server Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- OAuth 2.0 SAML Bearer Assertion Flow for Previously Authorized Apps (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Give Integration Users API Only Access (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Retirement of OAuth 2.0 Username-Password Flow for Connected Apps (Release Update) (opens in a new tab) (Salesforce Release Notes, Summer ‘26; checked 2026-11-07)