Briefly: the OAuth settings on a connected app decide who can authorise it, the scopes decide what the resulting token can reach, and the policies decide how long that token survives and from where it works. Most orgs configure the scopes carefully and then leave every policy on its default, which produces refresh tokens that live forever, usable from any address on the internet, by anyone with a Salesforce login. The four settings below are where the actual security lives.
Permitted Users
Two values. All users may self-authorise means any user who can log in can complete the OAuth flow and get a token for this app. Admin approved users are pre-authorised means only users with the app’s profile or permission set assigned can do so, and everybody else gets refused at the consent screen.
Pre-authorisation is the correct setting for anything that is not a broadly distributed tool. It turns the connected app into something you grant, which means you can also revoke it by removing a permission set rather than by hunting through OAuth tokens.
The catch: switching an existing app to admin-approved immediately breaks every user who is not in the assigned set. Assign the permission set first, then change the policy.
IP Relaxation
Three options, and the names are misleading.
- Enforce IP restrictions. The user’s profile login IP ranges and the org’s trusted IP ranges apply to sessions created through this app.
- Enforce IP restrictions, continue to enforce on refresh. The same, plus the check runs again each time the refresh token is exchanged. This is the one you want for an integration pinned to fixed infrastructure.
- Relax IP restrictions. The app bypasses those ranges entirely.
Relaxation exists for genuinely mobile clients. It is also what people reach for when an integration fails from a new server, which is how a profile restriction stops applying without anybody recording that it did.
Refresh Token Policy
The choices run from permanent to aggressively short: valid until revoked, expire immediately, expire if unused for a set period, or expire after a fixed period regardless of use.
Valid until revoked is the default and is right for a server integration you monitor, because a refresh token that expires at three in the morning is an outage. Expire if not used for a period is the best general setting for user-facing apps: abandoned authorisations clean themselves up, active ones never notice.
Immediately expire refresh token turns the app into access-token-only, which forces a full re-authorisation every hour or so. Use it where a long-lived credential is unacceptable and a human is present to re-authorise.
Whatever you choose, your client needs to handle a refused refresh cleanly: fail the call, raise an alert, and do not retry in a loop against an endpoint that will keep saying no.
Session Policies
The timeout value on the connected app overrides the profile and org session settings for sessions this app creates. Shorter is better for high-privilege integrations, though it has no effect on an integration that just re-authenticates.
High Assurance session required is the interesting one. Set it, and the app’s sessions must reach high assurance, which in practice means multi-factor authentication happened. Combine it with session-level security on sensitive Apex or reports and you get an app that can only touch the sensitive material when the user verified properly.
The settings next to them
Require a secret for the web server flow and for the refresh token flow: both should be on unless you are dealing with a public client that genuinely cannot hold a secret, in which case require proof key for code exchange instead. Client Credentials flow needs an explicit run-as user nominated on the app, and that user’s permissions become the app’s permissions, so nominate a purpose-built integration user rather than whoever set it up.
Changes to connected app policies do not always take effect instantly. Allow several minutes before concluding a change did not work.
Frequently asked
Where do I see who has authorised an app? Setup, Connected Apps OAuth Usage, then view the app’s user list. You can revoke an individual authorisation from there, and that is the fastest kill switch when a token leaks.
Does blocking the app kill live sessions? Blocking prevents new authorisations and revokes existing tokens for the app. Sessions already established behave less predictably, so treat blocking plus revoking as the pair.
Can I stop users installing their own OAuth apps? Yes. The API Access Control settings let you restrict access to an allowlist of approved connected apps, which is the org-wide control rather than a per-app one.
