Skip to content
SteveTechArcSteveTechArc Courses

Who May Use It, and How

Module 2 of 5 in the chapter External Client Apps, Tokens and Their Lifecycle, chapter 13 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: Which settings decide who can use an app, what it can do, from where, and for how long?

Five questions

Section titled “Five questions”

Module 1 said the admin’s half of an app is its policies. Here they are, as five questions to ask about every app in your org: the ones you build and the ones you install.

Five questions for every app Five questions for every app, each with its setting and its narrow answer. Who may use it? Permitted Users, self-authorize or admin approved and pre-authorized; narrowly, a permission set of named users, and watch Use Any API Client. What may it do? Scopes, set on the app; narrowly, only what it needs, api rather than full, and refresh_token only if it must. From where? IP rules, the org's and the refresh token IP allowlist; narrowly, the addresses it runs from, for a server-to-server app. How long, and how strong? Session policies, a timeout and high assurance required; narrowly, short, and MFA for what's sensitive, since high assurance needs a person approving. Which apps at all? API Access Control, from Salesforce Support; narrowly, only apps you approved, so everything else can't reach the API. Footnote: ask all five for every app, your own and the ones you install. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-05", "id": "DGM-IAM-AT-02", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE QUESTION THE SETTING THE NARROW ANSWER Who may use it? Permitted Users self-authorize, or admin approved and pre-authorized A permission set of named users and watch Use Any API Client What may it do? Scopes set on the app Only what it needs api, not full; refresh_token only if it must From where? IP rules the org's, and the refresh token IP allowlist The addresses it runs from for a server-to-server app How long, and how strong? Session policies timeout; high assurance required Short, and MFA for what's sensitive high assurance needs a person approving Which apps at all? API Access Control from Salesforce Support Only apps you approved everything else can't reach the API set by narrowly set by narrowly set by narrowly set by narrowly set by narrowly Ask all five for every app, your own and the ones you install. HOW TO READ IT the narrow answer © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Who may use it?

Section titled “Who may use it?”

The Permitted Users policy has two answers (S16; chapter 11):

  • All users may self-authorize. Anyone in the org can approve the app for themselves, on the Allow screen.
  • Admin approved users are pre-authorized. Only users “with the associated profile or permission set” can use it (S16), and they don’t see the Allow screen.

For anything that matters, choose the second, and use a permission set holding only the people who need it, not a whole profile. Chapter 11 showed why: a profile on the list means everyone in it.

Two warnings from Salesforce’s own page (S16). Switch an app from self-authorize to pre-authorized, and “anyone using the app loses access, unless a user’s permission authorizes the external client app specifically”: so assign the permission set first. And there’s a permission that walks straight past the list: “if users have the Use Any API Client permission, they can access any external client app—even if its Permitted Users setting is set to Admin-approved users are pre-authorized… you’re giving up your control over authorization” (S16). Know who has it.

What may it do?

Section titled “What may it do?”

That’s the scopes, set on the app. In my video on setting up an app, I chose one scope, manage user data through the APIs, and nothing else. The scopes determine what capabilities the app gets. Chapter 8 went through them: api, refresh_token, openid and the rest.

The narrow answer: only what it needs. api, not full. And refresh_token only if the app really has to come back without asking again, because module 3 is about everything that a refresh token makes possible.

From where?

Section titled “From where?”

The org’s own IP rules apply to logins. For an app that runs on servers with fixed addresses, there’s more: Enforce Refresh Token IP Allowlist means “only IPs in allowed ranges can complete the OAuth web server flow or the refresh token flow” (S6). A refresh token stolen and used from somewhere else then gets nothing.

How long, and how strong?

Section titled “How long, and how strong?”

The session policies (S7):

  • The timeout: how long an access token from this app lasts. Salesforce checks the app first, then the user’s profile, then the org’s session settings.
  • High assurance session required: users must “verify their identity with two-factor authentication” to use the app. Good for the apps that reach the most sensitive data.
  • Block this application: “Blocking an app ends all current user sessions with the connected app and prevents all new sessions.” The emergency stop.

One limit to know. High assurance works only for “authorization flows that include a user approval step”: the web server and refresh token flows. Flows with no person approving, such as JWT bearer, can’t meet it (S7). That makes sense: high assurance is about how strongly a person signed in.

Salesforce’s page for these is written for connected apps, so the names on an external client app’s policies page may differ a little.

Which apps at all?

Section titled “Which apps at all?”

The four questions above are about one app. The last is about all of them. API Access Control lets you “restrict all users from accessing your Salesforce APIs unless they’re pre-authorized through an approved (allowlisted)” app, or limit customers and partners to apps installed in their site (S8). You request it from Salesforce Customer Support (S8). Its page is written for connected apps, so when you request it, ask how it covers your external client apps.

And one change already made for you: since September 2025, uninstalled connected apps are restricted, so only users with Approve Uninstalled Connected Apps, or Use Any API Client, can use an app that isn’t installed in your org (Summer ‘25; the shared security record). Install the apps you trust; the rest need a reason.

That’s another reason to watch Use Any API Client. It turns up in both places.

Test knowledge. In my experience, know the difference between self-authorize and admin pre-authorized, that scopes limit what an app can do, and what a high-assurance session policy requires.

What’s next

Section titled “What’s next”

Module 3: the re-entry pass, over time.

What an architect decides here

Section titled “What an architect decides here”
  • Pre-authorized users, through a permission set, for every app that matters.
  • Who holds Use Any API Client, and why.
  • The fewest scopes each app needs.
  • IP allowlists for server-to-server apps.
  • Which apps require high assurance, and whether to ask for API Access Control.

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.