Integration Security & Identity

An integration user is a machine identity—not a shared administrator

JSBC Labs27 September 20268 min read

A username is not an ownership model

A shared Salesforce administrator account is an attractive shortcut for integration teams. It already has API access, it avoids permission troubleshooting and it keeps delivery moving. It also gives unrelated workloads the same identity, the same excessive authority and the same failure domain. When an unusual update appears, nobody can prove which application performed it without reconstructing evidence outside Salesforce.

Treat an integration user as a machine identity with a documented purpose, owner and lifecycle—not as a spare human login. Salesforce Well-Architected guidance explicitly recommends a unique integration user for every integration so access can be scoped, transactions remain attributable and a compromise has a smaller blast radius. The useful unit is the workload: one calling application, bounded business capability and accountable team.

One identity should represent one workload

Creating an account named API User does not solve the problem if middleware, a warehouse and a vendor all use it. Disabling that account during an incident would stop every service. Expanding its permissions for one project would expand them all. Its login history identifies the shared credential, not the responsible workload.

Provision separate identities at the boundary you need to operate independently. Record the system, business capability, data classification, technical owner, business owner, support route and expected transaction pattern. A single platform may legitimately use more than one identity when its workloads have different privilege or availability requirements. The goal is not one user per HTTP client process; it is isolation that supports safe permissioning, monitoring and containment.

Design permissions from operations, not profiles

Begin with an operation inventory: which objects, fields, records, Apex endpoints and API actions must the workload use? Separate reads from writes and ordinary processing from exceptional administration. Then grant the smallest permission sets that satisfy those operations. ‘It might need this later’ is not a requirement, and Modify All Data is not an integration pattern.

The Salesforce Integration user license supports API-only accounts through the Minimum Access – API Only Integrations profile. Salesforce recommends adding the required capability with permission set licenses, permission sets or permission set groups. That is a baseline, not an automatic security outcome. Object and field permissions still need design, and record access still follows ownership, organisation-wide defaults, sharing and other data-access controls.

Authentication and authorisation are separate controls

OAuth proves how the application obtains a session; the integration user's permissions determine what that session can do. A correctly configured OAuth flow attached to a system administrator still produces an over-privileged token. Conversely, a least-privilege user with credentials copied into source code still has a fragile authentication design. Review both layers together, but never confuse one for the other.

For a server-to-server connection that does not act on behalf of an interactive person, Salesforce supports the OAuth 2.0 client credentials flow. The connected or external client application's run-as user supplies the Salesforce execution context. Select that identity deliberately, constrain the application's OAuth scopes and use the smallest Salesforce permission surface. Avoid the username-password flow where a suitable modern flow exists; Salesforce describes it as a special-case option because credentials pass back and forth.

Do not automate a human login

A named employee account is not a service account. The employee changes role, leaves, resets a password, receives new permissions and signs in interactively. Tying production integration availability to that lifecycle creates both operational fragility and misleading audit data. Exempting the account from human security controls to keep a script alive makes the design worse.

Use the authentication flow intended for the workload and keep the identity non-interactive where the license and use case permit it. Store client secrets and private keys in an approved secrets service, not code, spreadsheets or deployment metadata. Give the integration team a tested way to replace credentials without changing business logic. A machine identity should be operable without pretending to be a person.

Control outbound identity as carefully as inbound access

When Salesforce calls another system, hard-coded endpoints and secrets spread trust across Apex, Flow and deployment configuration. Named Credentials separate the callout endpoint from the external credential that defines authentication. External credential principals can be mapped through permissions, so the ability to use a particular external identity becomes an explicit authorisation decision rather than an incidental property of code.

Choose named-principal or per-user identity according to the business contract. A named principal is appropriate when the downstream system should see one service identity; per-user authentication is appropriate when user-level accountability and downstream authorisation must survive the call. The trade-off is real: shared service identity simplifies token management, while propagated identity provides stronger attribution and finer downstream control.

Rotation is a capability, not a calendar reminder

A policy that says ‘rotate quarterly’ is incomplete if rotation requires an outage or an emergency code change. Inventory the connected client, credential type, storage location, expiry, owner and dependent environments. Where the mechanism allows it, design overlap so a new secret or certificate can be introduced, verified and then made primary before the old one is revoked.

Rehearse rotation in a production-like environment, including token caches and middleware restarts. Record evidence that the old credential no longer works. Apply the same discipline to decommissioning: revoke tokens, disable unused clients, remove permission assignments and retire the user only after consumers are proven absent. Dormant credentials are still attack paths.

Observability should identify the workload

A dedicated identity creates useful telemetry only when teams watch it. Establish a normal pattern for API volume, operating hours, source locations, objects touched, error rates and data-export behaviour. Alert on meaningful deviations such as access outside the expected window, sudden bulk extraction or calls to a newly granted capability. Salesforce Well-Architected identity patterns recommend monitoring anomalous service-account API usage through Event Monitoring.

Carry a correlation identifier through Salesforce, middleware and the target system so one business operation can be traced across boundaries. Log the stable business key and outcome without exposing credentials or sensitive payloads. Keep the workload owner visible in operational documentation. ‘Salesforce API User changed the record’ should be the beginning of an investigation, not the most precise answer available.

Design the kill switch before the incident

During compromise or runaway automation, security needs to stop one workload without disabling every integration. Dedicated identities make that possible, but the runbook must state which control to use: revoke the client, disable the user, remove a permission assignment, block an endpoint or pause the consuming application. Each option has a different recovery path and business impact.

Test the containment procedure and define who can authorise it. Preserve evidence before cleanup, reconcile uncertain transactions and rotate credentials before restoration. If a team cannot explain how to stop, investigate and safely restart an integration, then its identity design is unfinished—even when authentication works perfectly on an ordinary day.

Make machine identity part of release governance

Permission changes, OAuth scope changes, certificate replacements and ownership transfers are production changes. Put them through source control or a controlled configuration process where possible, require peer review and test positive and negative access. Prove that the workload can perform every required operation and that representative forbidden operations remain forbidden. Least privilege without negative testing is an assumption.

The JSBC Labs view is that every integration should ship with an identity dossier: purpose, owners, authentication flow, permissions, record-access model, credential lifecycle, expected telemetry, containment procedure and retirement criteria. Review it when the interface changes and recertify high-impact identities periodically. A machine identity is well designed when its authority is explainable, its activity is attributable and its removal is safe—not merely when a token can be issued.