Checkpoint challenge

Original, hands-on practice. Never modeled on actual exam questions. This closes the chapter External Client Apps, Tokens and Their Lifecycle, chapter 13 of Securing Salesforce: Identity and Access.

Scenario

By now your two lab orgs have collected apps: the SAML app from chapter 7, the command-line tool from chapter 9, the service provider org login from chapter 10, the Burger House from chapter 11, and maybe more. Each one worked. Nobody has looked at them since.

That’s every org I’ve ever walked into. So be the admin who looks.

Requirements

• An inventory of every app in each org, from the Insights page.
• One app narrowed: its scopes, who may use it, rotation on.
• Rotation seen working: a reused refresh token refused.
• Access taken back, and the app made to ask again.
• High assurance required on one app where a person signs in.

Constraints

• Lab orgs only. No company data, nothing personal.
• Never for an admin. Both admins keep a password and MFA.
• Assign before you restrict. In step 3, give the permission set first, or the app stops working for everyone (S16).

Your task

1. Take the inventory. In each org, from Setup, open Insights (S5). List every app, local or packaged, enabled or not. In the Security Controls column, which ones are missing controls? For one of them, open Configure Security Posture from its actions menu and note what it’s missing. If the page looks a little different in your org, look for the list of apps with their security controls.

2. Narrow the scopes. Open chapter 9’s Command-line tool. Its scopes are api and refresh_token. Does it need anything else? No. Does anything you added later need to go? Take it out. Write down, in one line, what each scope it keeps is for.

3. Say who may use it. First, create a permission set, “Command-line tool users”, and assign it to your test user. Then, in the app’s policies, set Permitted Users to Admin approved users are pre-authorized, and add the permission set (S16). Who in your org has Use Any API Client? Check: they’d walk straight past this (S16).

4. Turn on rotation. In the app’s OAuth settings, make sure Enable Refresh Token Rotation is on (S6). If the app was made after July 2026, it probably already is.

5. Get a refresh token, and use it. Run chapter 9’s device flow again (its steps 3 to 5), as your test user, and copy the refresh_token from the answer. Now use it once:

curl -s -X POST https://YOUR-DOMAIN.my.salesforce.com/services/oauth2/token -d grant_type=refresh_token -d client_id=YOUR_KEY -d refresh_token=FIRST_REFRESH_TOKEN

You get a new access token, and, with rotation on, a new refresh token. Keep both refresh tokens: the first and the second.

6. Be the thief. Try the first refresh token again, as if someone had copied it. It’s refused. Now try the second one, the good one. Refused too: when a rotated-out token is used, “Salesforce invalidates the current refresh token and any associated access tokens” (S6). The thief got nothing, and the real app has to ask again. The words of each refusal can change from release to release; what matters is that both are refused.

7. Take it back, as the admin. Run the device flow once more, so the app has a fresh refresh token. Then, as the admin, open the OAuth Usage page for external client apps, find the Command-line tool, and revoke your test user’s access, or block the app (S9). Try the refresh token: refused. The app must start again from the beginning. If you can’t find a way to revoke one user there, block the app for the test, then unblock it.

8. Require high assurance. Open chapter 10’s Service provider org login app, in the identity provider org: the one Priya uses through the auth provider, a flow where a person signs in and approves. In its session policies, select High assurance session required (S7). Log in to the service provider org through the identity provider org as Priya. What changes? She must have signed in with MFA. On an external client app, look for the setting among the app’s session policies.

9. Look again. Back on the Insights page: what’s still missing? Write down what you’d do about each, and when.

Discussion

Why did the good refresh token stop working in step 6? Because Salesforce can’t tell which copy is the thief’s. It sees a token that should be dead being used, and kills everything in that chain. Someone has to sign in again, and that’s how someone notices.

Why did step 3 come with a warning? Because switching to pre-authorized users is a lock with no key until the permission set is there. Assign first, restrict second.

Why high assurance on chapter 10’s app, and not on chapter 11’s Burger House? High assurance only works for flows with a person approving (S7). JWT bearer has nobody to ask for MFA.

What would you add for a server-to-server app? An IP allowlist for the addresses it runs from (S6), and no refresh_token scope if it doesn’t need one.

What did the inventory find that nobody remembered? In every real org, something. That’s the point of step 1.

Check your lab

• The inventory: every app, and what each is missing.
• The Command-line tool: two scopes, pre-authorized through a permission set, rotation on.
• Rotation: the old refresh token refused, and the new one with it.
• The revoke: the refresh token refused after the admin took it back.
• High assurance: on chapter 10’s app, and Priya asked for MFA.

Exam objectives exercised

• IDP-2 and AMB-4 (the app’s scopes and configuration).
• IDP-3 (tokens, refresh, expiry, revocation).
• AMB-1 (MFA, and the high-assurance session).

Explore

• Configure the External Client App OAuth Settings (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
• Monitor App Security Controls on the Insights Page (opens in a new tab) (Winter ‘27 release notes; checked 2026-11-07)