Skip to content
SteveTechArcSteveTechArc Courses

Steve Trucking

Module 5 of 5 in the chapter External Client Apps, Tokens and Their Lifecycle, chapter 13 of Securing Salesforce: Identity and Access, and the end of Part 2. Original practice, never modeled on actual exam questions.

The question this checkpoint answers: Can you take every line that reaches a company’s API and set it up properly: the flow, the app, its policies and its tokens?

Scenario

Section titled “Scenario”

At the end of Part 1, in Checkpoint 1, you gave the CIO one page: who signs in to Steve Trucking’s Salesforce, and the door for each. Staff through Entra ID. Retail Partners through their own identity providers. Small carriers with logins on the partner site. Crews in the mobile app. Recipients with a tracking link, and social sign-on for those who want an account. The route data service and the integration layer with no person at all. And finance’s rule: a change to a customer’s credit terms must show the account manager who approved it.

The CIO liked it. Now the security team wants the next page: for every line that reaches the API, how exactly it’s set up. And they’ve read the news (module 4), so they have two more questions.

And one new request has arrived. What if: a large Retail Partner wants its own system to read the status of its deliveries through the API, every few minutes, with no person involved. (A labelled what if: it isn’t in Steve Trucking’s design yet.)

Requirements

Section titled “Requirements”
  • Every line that reaches the API has its own app, and you can say why it’s separate.
  • Each app answers module 2’s five questions: who, what, from where, how long and how strong, which apps at all.
  • Each app has a token policy: refresh tokens or not, rotation, the idle limit, IP allowlist, DPoP.
  • Nothing on module 4’s retired list.
  • A plan for two bad days: a crew member’s phone is lost, and a partner says it’s been breached.

Your task

Section titled “Your task”
  1. Find the lines that reach the API. From Checkpoint 1’s page, separate the lines that only sign a person in to Salesforce’s pages, in a browser, from the lines where a program or an app calls the API. Only the second kind needs an app.
  2. Draw each one’s swim lane, from Part 2: who’s in it, what’s presented, what comes back.
  3. Give each one its app, and answer module 2’s five questions for it.
  4. Choose each one’s token policy. Does it need a refresh token at all? If it does: rotation, the idle limit, an IP allowlist? Which would you protect with DPoP?
  5. Answer the what if.
  6. Write the two runbooks: the lost phone, and the breached partner.
  7. Check the list against module 4: nothing retired, and no secret anywhere it shouldn’t be.

Try it before you read on.

Discussion

Section titled “Discussion”

Here’s one answer. Yours may differ in the details; what matters is that you can say why.

Checkpoint 2: Steve Trucking's apps and tokens One answer for Checkpoint 2: each line that reaches the API, with its flow and app, and its policies and tokens. Crews' mobile app, a person through an app, uses the web server flow with PKCE in its own app, with no secret on the phone, with the crews' permission set, rotation, refresh tokens with the 30-day idle limit, and a revoke on a lost phone. The route data service, no person, overnight, uses client credentials with its own app and integration user, with few scopes, its addresses only, no refresh token, and its secret in a vault. The integration layer, no person, all day, uses client credentials in a separate app from the route service, with its own integration user and scopes for its objects only. Finance's credit terms rule, which needs a named account manager, uses JWT bearer with the integration layer's certificate, with the account managers' permission set only, never a profile, and the key in a vault. Recipients' accounts, with social sign-on as an option, use an auth provider, where Salesforce is the client, chapter 10, with a handler that only matches deliveries, and PKCE on the auth provider. And a labelled what if, not in the master model: a Retail Partner's system reading its own deliveries uses client credentials with its own app and integration user, with access to its deliveries only, its addresses only, DPoP if it can, and a revoke runbook ready. Footnote: staff, Retail Partners and small carriers sign in through browsers, with single sign-on and site logins and no app of their own; every app here is on the Insights page. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-05", "id": "DGM-IAM-AT-06", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE LINE FLOW AND APP POLICIES AND TOKENS Crews' mobile app a person, through an app Web server flow with PKCE its own app; no secret on the phone Crews' permission set; rotation refresh tokens, 30-day idle; revoke on a lost phone Route data service no person, overnight Client credentials its own app and integration user Few scopes; its addresses only no refresh token; secret in a vault Integration layer no person, all day Client credentials a separate app from the route service Its own integration user scopes for its objects only Finance's credit terms rule a named account manager JWT bearer the integration layer's certificate Account managers' permission set only never a profile; the key in a vault Recipients' accounts social sign-on, an option An auth provider Salesforce is the client · ch 10 A handler that only matches deliveries PKCE on the auth provider What if: a Retail Partner's system reading its own deliveries Client credentials its own app and integration user Its deliveries only; its addresses DPoP if it can; a revoke runbook ready uses with uses with uses with uses with uses with uses with Staff, Retail Partners and small carriers sign in through browsers: single sign-on and site logins, no app of their own. Every app here is on the Insights page. HOW TO READ IT the narrowest settings that still work a labelled what if, not in the master model © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Which lines need an app? Staff, Retail Partner users and small carriers sign in to pages in a browser: single sign-on and site logins, chapters 4, 6 and 14. No app of their own. Everything else calls the API, and every one of those gets its own app. Why separate? So each has its own policies and its own tokens, and you can block one without stopping the others (module 2).

Crews: the web server flow with PKCE (chapter 9). It’s a person, through an app, on a phone that can’t keep a secret, so no client secret in the app, and PKCE on. Admin pre-authorized, through a crews’ permission set. A refresh token, because nobody wants to log in at every stop, with rotation and the 30-day idle limit, on by default for a new app. High assurance? It would make every driver do MFA again; save it for the apps that reach the most sensitive data.

The route data service and the integration layer: client credentials (chapter 8), each with its own app and its own integration user. Should we just use one integration user for both? No: different jobs, different access, and you want to switch one off without the other. Few scopes. An IP allowlist for the addresses they run from. No refresh token: client credentials doesn’t need one. The secret in a vault, never in code.

Finance’s rule: JWT bearer (chapter 11). The integration layer signs a JWT naming the account manager, with its own certificate on a separate app. Pre-authorized through a permission set holding only the account managers, never a profile, and never anyone with Use Any API Client. The private key is the most important secret on the page.

Recipients: an auth provider (chapter 10). Salesforce is the client here, so the app is at the social provider; Salesforce’s side is the auth provider, with PKCE on, and a registration handler that only creates a user when there’s a delivery to match her to.

The what if: client credentials, done narrowly. The partner’s system is a program, with no person, so client credentials, with its own app and an integration user that can see only that partner’s deliveries (the Sharing and Visibility course has the how). Its addresses only. DPoP if their developers can do it. And the runbook ready, because this is module 4’s second door: a partner’s stored tokens.

The two bad days. A lost phone: revoke that driver’s refresh token, or have them revoke it themselves (module 3); with rotation on, a copy used later is caught anyway. A breached partner: block the partner’s app on the OAuth Usage page, revoke its tokens, rotate its secret, read the logs, and talk to the partner (module 3, module 4).

What’s not on the page. No username-password flow, no user-agent flow, no SOAP login(), no session IDs going out, no device flow on a connected app (module 4). No secrets in records. And every app above shows up on the Insights page, with its controls on.

Count them: six apps or auth providers, each with its own policies, each one something you can see, narrow, and take back. That’s Part 2.

Exam objectives exercised

Section titled “Exam objectives exercised”
  • IDP-2 (app scope and configuration) and AMB-4 (the app’s configuration settings): an app per line, with its scopes and policies.
  • IDP-3 (OAuth implementation concepts): secrets, tokens, refresh, expiry and revocation, in each token policy and the two runbooks.
  • AMB-1 (MFA and the session it produces): where high assurance belongs, and where it doesn’t.

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.