Connected App Access Policies

Why Connected App Access Policies Matter

Every time an external application, mobile app, or integration talks to Salesforce through OAuth, it does so through a Connected App. The access policies attached to that Connected App are the control panel that determines who can use the app, from where they can use it, how long their access lasts, and what extra security (such as multi-factor authentication or a high-assurance session) is required. If you misconfigure these policies, you either lock out legitimate users or, far worse, leave an open door for stolen tokens and unauthorised API access.

For the Advanced Administrator exam, this topic sits inside the Advanced Security and Access domain. Expect scenario-based questions that describe a business requirement (for example, 'only approved users may use the mobile app' or 'sessions must expire after one hour of inactivity') and ask you to pick the correct policy setting. Knowing the exact names of the settings and what each one does is the key to scoring well.

What Is a Connected App?

A Connected App is a framework that lets an external application integrate with Salesforce using APIs and standard protocols such as OAuth 2.0, SAML, and OpenID Connect. It defines:

• A Consumer Key and Consumer Secret (the app's credentials)
• A Callback URL where Salesforce returns the user after authentication
• OAuth Scopes that define what the app is permitted to do (for example, api, refresh_token, full, web, openid)

Connected Apps are created under Setup > App Manager > New Connected App. Once created, administrators manage their security behaviour under Setup > Manage Connected Apps (or by clicking Manage from App Manager). This is where access policies live.

Important nuance: Connected Apps installed from the AppExchange or provided by Salesforce (such as Salesforce Mobile) also appear under Manage Connected Apps, and you can apply the same policies to them even though you did not build them.

The Core Access Policies and How They Work

1. Permitted Users (OAuth Policy)
This is the single most tested setting. It has two values:

• All users may self-authorize – Any user with the correct login can access the app. The first time they use it, they see an OAuth consent screen asking them to allow access. This is the default.
• Admin approved users are pre-authorized – Only users whose Profile or Permission Set has been explicitly assigned to the Connected App can use it. Users do not see a consent screen because the administrator has already approved on their behalf. Everyone else is blocked.

When you choose Admin approved users are pre-authorized, two new related lists appear on the Connected App detail page: Profiles and Permission Sets. You add the appropriate profiles or permission sets there. Exam tip: if the scenario says 'restrict the app to a specific group of users' or 'users should not have to approve the app', the answer is Admin approved users are pre-authorized plus assignment via profile or permission set.

2. IP Relaxation
This controls whether the organisation's or profile's login IP ranges are enforced when a user authenticates through the Connected App. Options:

• Enforce IP restrictions – Users must be within the login IP ranges defined on their profile. The strictest setting.
• Relax IP restrictions with second factor – If the user is outside the trusted IP range, they can still get in but must complete identity verification (MFA challenge).
• Relax IP restrictions – IP ranges are ignored entirely for this app. Useful for mobile apps where users roam between networks.
• Relax IP restrictions for activated devices – Users on a device that has already completed identity verification bypass IP restrictions; new devices must verify.

Exam tip: if the scenario mentions 'field sales reps using the mobile app from different locations' and 'profile login IP ranges are blocking them', the fix is an IP Relaxation setting, typically Relax IP restrictions or Relax IP restrictions with second factor if security is a stated concern.

3. Refresh Token Policy
A refresh token lets the app obtain a new access token without asking the user to log in again. The policy controls how long that refresh token stays valid:

• Refresh token is valid until revoked – Never expires unless an admin or user revokes it. Most convenient, least secure.
• Immediately expire refresh token – Effectively forces re-authentication every time the access token expires.
• Expire refresh token after X – Fixed lifetime (for example, 90 days) regardless of usage.
• Expire refresh token if not used for X – Inactivity-based expiry; frequent users stay logged in, dormant users are cut off.

Exam tip: 'Users who have not used the app in 30 days must log in again' maps to Expire refresh token if not used for 30 days. 'Everyone must re-authenticate every 90 days no matter what' maps to Expire refresh token after 90 days.

4. Timeout Value (Session Timeout)
You can set a session timeout specific to this Connected App that overrides the organisation-wide session timeout found in Session Settings. If left as None, the org or profile session timeout applies. Exam tip: when the question asks for an app-specific session length that differs from the org default, the answer is the Connected App's Timeout Value, not the org-wide Session Settings.

5. High Assurance Session Required
When enabled, users must have a high-assurance session to access the app. A high-assurance session is typically obtained by completing MFA at login. If the user's current session is only standard assurance, Salesforce prompts them to raise the session level before granting access. This is the Connected App equivalent of the session security level policies used for reports, dashboards, and Setup. Exam tip: 'require MFA before using this integration' or 'only trusted sessions may use the app' points to High assurance session required.

6. Single Logout and Session Policies
For SAML-enabled Connected Apps, you can require that logging out of Salesforce also logs the user out of the connected app. Additional session policy options can require users to re-enter their password or complete identity verification within the app at defined intervals.

7. Mobile App Policies
For mobile Connected Apps (Salesforce Mobile, Mobile Publisher apps, and custom mobile apps), you can enforce:

• Require PIN after X minutes of inactivity
• PIN length
• Whether the app may run on jailbroken or rooted devices
• Clipboard, custom attributes, and offline data controls

Exam tip: 'Users must enter a PIN when the mobile app is idle for 10 minutes' is a mobile app policy on the Connected App, configured under Manage Connected Apps.

8. Custom Attributes and Start URL
You can define a Start URL so that users launching the app from the App Launcher land on a specific page, and you can pass custom attributes to the app. These are less about security and more about user experience, but they do appear on the same management page.

Managing and Monitoring Access

Connected Apps OAuth Usage (Setup > Connected Apps OAuth Usage) lists every Connected App that users in your org have authorised, how many users have used each, and lets you Install, Block, or Uninstall apps. Blocking an app immediately revokes all tokens and prevents any new authorisation. This is the first place to look when the question says 'an unknown app is accessing our data' or 'we need to stop an integration immediately'.

User-level revocation: On an individual user record, the OAuth Connected Apps related list shows every app that user has authorised. An administrator (or the user themselves from their personal settings) can click Revoke to kill that user's tokens for a specific app without affecting anyone else.

Login History shows the Connected App used for each login, so you can audit which integrations are generating API traffic.

API Access Control (API Client Allowlisting)
This is an org-wide, advanced feature that must be enabled by Salesforce Support. Once enabled, no Connected App can access the org via API unless it is explicitly approved (pre-authorised with profiles or permission sets). Users who need unrestricted access can be granted the Use Any API Client user permission. Exam tip: if the requirement is 'block every unapproved third-party application from connecting to our org via API', the answer is API Access Control, not individual Connected App policies.

Putting It Together: A Worked Scenario

Universal Containers has a custom mobile app. Only members of the Field Service team should be able to use it, they travel constantly so profile IP ranges must not block them, but the company wants MFA if they connect from an unknown network, and anyone who has not used the app for 60 days must log in again.

Correct configuration:
• Permitted Users = Admin approved users are pre-authorized, assign the Field Service profile or a permission set
• IP Relaxation = Relax IP restrictions with second factor
• Refresh Token Policy = Expire refresh token if not used for 60 days

Notice that one scenario touches three separate policies. The exam loves this pattern, so read every sentence of the question and map each requirement to its own setting.

Exam Tips: Answering Questions on Connected App Access Policies

Tip 1 – Learn the exact option names. The exam uses the real UI labels. Know the difference between All users may self-authorize and Admin approved users are pre-authorized, and the four IP Relaxation options word for word.

Tip 2 – 'Restrict who can use the app' always means pre-authorisation. Whenever a question asks to limit a Connected App to certain users, choose Admin approved users are pre-authorized and then assign profiles or permission sets. Distractors will suggest sharing rules, roles, or org-wide defaults, none of which control Connected App access.

Tip 3 – Separate IP from session from token. Questions often blend location, duration, and re-authentication requirements. Ask yourself: Is this about where (IP Relaxation), how long a session lasts (Timeout Value), or when the user must log in again (Refresh Token Policy)?

Tip 4 – 'Mobile users blocked by IP ranges' means IP Relaxation. Do not pick 'remove the login IP ranges from the profile' when a less drastic Connected App setting solves the problem.

Tip 5 – 'Not used for X days' versus 'after X days'. Inactivity-based expiry is Expire refresh token if not used for X; absolute expiry is Expire refresh token after X. The exam tests this distinction directly.

Tip 6 – MFA or trusted session requirements point to High Assurance. If the question says users must verify their identity or use MFA before the app works, select High assurance session required.

Tip 7 – Know where to revoke. To stop one user: the user's record, OAuth Connected Apps related list, Revoke. To stop everyone: Connected Apps OAuth Usage, Block. To stop all unapproved apps org-wide: API Access Control (enabled by Salesforce Support).

Tip 8 – Policies apply to installed and packaged apps too. You can and should apply access policies to Salesforce Mobile and AppExchange Connected Apps, not just apps you build yourself.

Tip 9 – Scopes are not access policies. OAuth scopes define what the app can do once connected; access policies define who can connect and under what conditions. If a question asks to limit the app to read-only API calls, that is a scope decision, not a policy decision.

Tip 10 – Eliminate the distractors. Wrong answers commonly include: changing org-wide Session Settings when an app-specific timeout is needed, using Login Hours or Login IP Ranges on the profile when IP Relaxation is the right lever, or deleting the Connected App when Block would suffice. Choose the most targeted, least disruptive setting that satisfies every requirement in the scenario.

Quick Reference Summary

• Who can use it – Permitted Users (self-authorize vs admin pre-authorized) plus Profiles and Permission Sets
• Where they can use it – IP Relaxation (Enforce / Relax with second factor / Relax / Relax for activated devices)
• How long a session lasts – Timeout Value
• When they must re-authenticate – Refresh Token Policy
• Security level required – High assurance session required
• Mobile protections – PIN, inactivity lock, jailbreak detection
• Monitoring and shutdown – Connected Apps OAuth Usage, user-level Revoke, Login History
• Org-wide lockdown – API Access Control with the Use Any API Client permission for exceptions

Master these mappings and you will be able to dissect any Connected App scenario the Advanced Administrator exam presents.