Skip to content
SteveTechArcSteveTechArc Courses

Study guide

Study guide for chapter 13 of the Integration Architect course. Read the eight modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter carries security across the exam: evaluating authentication from the landscape (LAND-3), the security requirements (REQ-3), the security mechanisms of a design (DES-5), and securing inbound and outbound integrations (BLD-5). Know which flows are retiring and why, one identity per integration, which OAuth flow fits which caller, and what a token can do when it’s stolen.

For the Exam

Section titled “For the Exam”

Tick them off as you go. Each one links to where it’s taught.

Security keeps changing (DES-5)

  • I know TLS 1.0 has been off in Salesforce production since March 4, 2017. (Thought Secure, Then Not)
  • I know the username-password flow (“directly passes the user’s credentials”) and the user-agent flows (“directly expose access tokens to the browser”) retire on February 20, 2027, replaced by the web server flow with PKCE or client credentials. (Fine for Its Time, Now Retired)
  • I know today’s hardening adds refresh token rotation and DPoP. (Secure Today, Still Being Hardened)

Protecting what crosses (REQ-3, DES-5)

  • I know TLS protects the channel hop by hop, and the data is readable again at each stop. (The Channel Ends at Every Stop)
  • I seal the payload end to end with the Apex Crypto class when it must cross intermediaries, and plan the keys. (Sealing the Payload)
  • I never store card numbers, card security codes or PINs: a payment gateway and tokens instead. (What Never Travels)
  • I know Private Connect keeps traffic between Salesforce and AWS off the public internet, inbound and outbound, as an add-on; inbound doesn’t support port 8443. (Not Over the Internet)

The three doors (LAND-3, BLD-5)

  • I know the three ways in from 2024 to 2026: talking someone into approving an app, a partner app’s stolen tokens, and over-permissive guest users. (The Person Door, The Partner Door, The Public Door)
  • I know the controls: block uninstalled apps for ordinary users and restrict the device flow; narrow scopes, IP restrictions, rotation and DPoP; secure guest settings. (Three Doors, One Picture)
  • I know Salesforce states the platform wasn’t compromised: these were configuration and shared responsibility. (The Platform Held. The Doors Didn’t.)

One integration, one identity (LAND-3, REQ-3, BLD-5)

  • I give every integration its own user, as Salesforce recommends, because shared identities fail together. (The Saturday Lockout, Salesforce Says It Too)
  • I know the Salesforce Integration user license and the Minimum Access - API Only Integrations profile, with permissions added through permission sets. (Five Gates)
  • I narrow each identity: scopes, IP restrictions, and API Access Control to allowlist approved apps. (Five Gates)

Choosing a flow (DES-5, BLD-5)

  • Client credentials: server to server, no person, an integration user runs it. (The Food Festival)
  • Web server with PKCE: a person signs in to a web app, which trades a code for tokens; PKCE protects the code. (The Burger House)
  • JWT bearer: server to server as a named user, signed with a certificate, the app pre-approved. (Acting for a User Who Isn’t There)
  • Token exchange for a token from another identity provider; the device flow only for limited-input devices. (The Rest, in a Line)
  • I can pick the flow with three questions: is a person there, must it be a named user or a certificate, is there already a token. (The Decision)

What to build on (DES-5, BLD-5)

  • I know inbound integrations use External Client Apps: settings by the developer, policies by each org’s admin. (Why External Client Apps)
  • I know the connected app dates: no new ones since Spring ‘26 without Support; end of support in Summer ‘27; the migration keeps the key and secret but not the username-password flow. (The Move Off Connected Apps)
  • I know outbound callouts use named credentials with external credentials, a named principal or per-user, granted through permission sets. (Going Out)

Tokens as a design decision (BLD-5)

Secrets (BLD-5)

  • I keep outbound secrets in named and external credentials, never in code, records or readable fields. (Where Secrets Live)
  • I know the order when a secret leaks: rotate, revoke the tokens it issued, then remove it. (When One Leaks)
  • I know client credentials token requests go to the My Domain URL, and a PKCE client can omit the secret. (Your Lab Bench)

Beyond the Exam

Section titled “Beyond the Exam”

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

  • Security keeps changing. Know what every integration uses, and keep a calendar of what retires.
  • Every integration opens a door. Ask who could approve it, what its token can do, and who’d notice.
  • One integration, one identity, each as small as its job.
  • A stolen token is exactly as powerful as you designed it to be.
  • Secrets live in places built to hold them, and every one has a plan for when it leaks.

Words to Know

Section titled “Words to Know”
TermIn one line
End-to-end encryptionThe payload sealed so even the stops in the middle can’t read it
Private ConnectSalesforce and AWS traffic kept off the public internet
Integration userA user for one integration, API only
API Access ControlOnly approved apps may use the API
Client credentials flowServer to server, no person
Web server flow with PKCEA person signs in to a web app; PKCE protects the code
JWT bearer flowServer to server as a named user, signed with a certificate
External Client AppThe new generation of connected apps, for every way in
Named credential, external credentialWhere a callout goes, and how it signs in
Refresh token rotationEach refresh token works once
DPoPA token bound to the client’s key pair

Check Yourself

Section titled “Check Yourself”

Short scenarios in the style of the course. Decide your answer before you open it.

1. An old integration signs in with the username-password flow. What's the deadline, and what replaces it?

It retires on February 20, 2027. Server to server with no person: client credentials, as an integration user. A person signing in: the web server flow with PKCE. Reread Fine for Its Time, Now Retired.

2. Payment data passes through middleware on its way to a partner, and the security team says the middleware mustn't read it. Is TLS enough?

No. TLS ends at every stop. Seal the payload end to end, for example with the Apex Crypto class, and plan who holds the keys. Reread The Channel Ends at Every Stop.

3. One integration user is shared by four integrations. One Saturday, one of them breaks. What happens to the other three?

They break too: a lockout, or a reused rotated refresh token, cuts off everything on that identity. One integration, one identity. Reread The Saturday Lockout.

4. A nightly job updates records with no person present, and the audit must show the job did it. Which flow?

Client credentials, with an integration user named for the job. If every change must carry a specific named user, or be signed with a certificate, the JWT bearer flow. Reread The Decision.

5. A team plans a new connected app for an integration next quarter. What do you say?

Build it as an External Client App. New connected apps need Support since Spring ‘26, and connected apps reach end of support in Summer ‘27. Reread The Move Off Connected Apps.

6. A quarterly integration stops working every time it runs. Its refresh token "was fine last quarter". Why?

From November 4, 2026, refresh tokens idle for 30 days expire in production. Run it more often, or use a flow that doesn’t depend on a long-idle refresh token, such as client credentials. Reread An Unused Pass Expires.

7. A partner app's tokens were stolen from the partner's systems. What limits the damage in your org?

The integration user’s narrow permissions, narrow scopes, IP restrictions, rotation, and DPoP where available; and the ability to revoke the tokens at once. Reread What a Stolen Token Can Do.

8. An API key was found in a case description. What do you do, in order?

Rotate it first, revoke what it issued, then remove it from the record, and move it into a named or external credential. Reread When One Leaks.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.