Trust, Identity, and Integration Security

Chapter 13 of Integration Architect, Part 2: Designing Integrations That Work (Design). Previous: Keys, Certificates and Trust · Next: Reliability, Recovery, and Observability.

Chapter 12 gave you the ground under every integration: keys, certificates, and the handshake that lets two systems trust each other. This chapter builds the integration on top of it.

Between 2024 and 2026, data was taken from a lot of Salesforce orgs, and in every case Salesforce and the outside investigators say the platform wasn’t broken into. The attackers came through doors that were part of how the orgs were set up, and how their integrations were trusted. That’s good news for an architect. Every one of those doors was a design decision, and design decisions can be changed.

Steve Trucking runs through the chapter: the integration layer with two identities, FleetLink and the bulk loading tool with one each, the partners whose tokens sit on someone else’s servers, and a lab bench where you sign in from Postman the way an integration should.

The ideas in this chapter

Security keeps changing. FTP was never safe, TLS 1.0 was thought secure and then wasn’t, two OAuth flows retire on February 20, 2027, and today’s tokens are still being hardened. Something secure yesterday may not be secure today or tomorrow.
The channel ends at every stop. TLS protects each hop; the data is readable again in the middle. Seal the payload when you can’t trust the stops, keep card numbers and PINs out entirely, and use Private Connect when the road mustn’t be the public internet.
Three doors, one kind of call. A person talked into approving an app, a partner’s stored token, a public site’s guest user: all three end in an API call that looks legitimate. Close the doors, and watch the calls.
One integration, one identity. Shared identities fail together, with a password or with a token. Each identity goes behind five gates: the license, the permission set, the scopes, where it comes from, and which apps may call.
Three questions pick the flow. Is a person there? Must it act as a named user or sign with a certificate? Does it already hold another identity provider’s token? Otherwise, client credentials: the food festival.
Two gates. Every way in is an External Client App; every way out is a named credential. Connected apps reach end of support in Summer ‘27.
A token is a design decision. Each refresh token works once, an idle one expires after 30 days, every token can be taken back, and with DPoP it only works where it was issued.
Secrets live where they’re meant to. Never in a record, code, a message or an AI prompt. If one leaks: rotate, revoke, remove, review.

The path through this chapter

Eight modules, each standing on its own.

Security Keeps Changing. A protocol that was never safe; thought secure, then not; fine for its time, now retired; secure today, still being hardened; four steps, one lesson.
Protecting What Crosses. The channel ends at every stop; sealing the payload; what never travels; not over the internet; proving the caller; five layers.
The Three Doors. The platform held; the person, partner and public doors; the same room at the end; what it means for your integrations.
One Integration, One Identity. The Saturday lockout; the same failure with tokens; Steve Trucking’s identities; five gates.
Choosing a Flow. The food festival; the burger house, with PKCE; acting for a user who isn’t there; the rest in a line; the decision.
What to Build On. Two gates; why External Client Apps; the move off connected apps; design choices in a named credential.
Tokens as a Design Decision. The wristband and the re-entry pass; rotation; the 30-day limit; taking it back; DPoP; what a stolen token can do.
Secrets. The secret in the description field; where secrets live; when one leaks; your lab bench.

Chapter 14 takes the watching: how you notice the normal-looking call that isn’t normal, and how an integration recovers when something does go wrong.

When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions.

What an architect decides here

For every integration: how it travels and how it signs in, in the inventory, with the date you checked and what retires next.
What crosses, and how far it’s protected: TLS on every hop, a sealed payload where the middle can’t be trusted, and what never travels at all.
Who may approve apps, what each token can do, and what answers without a login, sized to what happens if a partner is broken into tomorrow.
One identity per integration and per job, behind its five gates, and how each is retired.
The flow for each caller, and the move off every retiring flow and connected app before its date.
Each token’s life: rotation on, the idle limit planned for, a revocation runbook, and DPoP where tokens sit at a partner.
Where every secret lives, who owns it, when it rotates, and what happens the day one leaks.

Beyond the exam: an AI assistant will write the OAuth call, the callout and the Postman request in a minute. What it won’t decide is which identity the integration runs as, what its token may reach, or where its secret is kept. And it should never be given the secret to help. Those decisions are this chapter.

Explore

Salesforce Help, OAuth Authorization Flows (opens in a new tab): every flow and when to use it.
Salesforce Help, Give Integration Users API Only Access (opens in a new tab): one Salesforce user for every integration, in Salesforce’s words.
Salesforce Architects, Well-Architected: Trust (opens in a new tab): Salesforce’s own framework for secure, compliant solutions.

Next: Reliability, Recovery, and Observability