Manage Connected Apps
Manage Connected Apps is the Salesforce Setup page where an administrator governs every Connected App installed in or created within an org.
Definition
Manage Connected Apps is the Salesforce Setup page where an administrator governs every Connected App installed in or created within an org. A Connected App is a configuration record that lets an external application authenticate to Salesforce through OAuth 2.0 and related identity protocols. The page is the control surface for those records: it lists each app, opens its policies for editing, and ties each app to the profiles and permission sets allowed to use it.
From this one place an admin decides who may authorize an app, how strictly IP rules apply, how long refresh tokens stay valid, and which session policies are enforced. Because every Connected App is a doorway for outside access, the page is also a security boundary. Loose policies or forgotten apps quietly widen the attack surface, so the work done here matters as much as the apps themselves.
How the page governs OAuth access
Getting to the page and what it lists
You reach the page from Setup by typing Connected Apps in Quick Find, then selecting Manage Connected Apps. The list shows every app available in the org, whether it arrived through a managed package or was built locally. Each row links to that app's detail and its editable policies. This is distinct from the Connected Apps OAuth Usage page, which is a separate monitoring view covered later. Manage Connected Apps is where you set policy; OAuth Usage is where you watch live sessions and cut them off. Next to an app you click Edit to open the access settings, then Edit Policies for the full OAuth policy set. The same area lets you attach profiles, permission sets, custom attributes, and custom scopes to the app. Treat the list as an inventory. Most orgs accumulate apps faster than they remove them, so periodically reading down this list is the first step in any security review. An app you do not recognize is worth investigating, because it represents a standing OAuth relationship that someone, at some point, authorized for external access.
Permitted Users: who may authorize an app
The Permitted Users setting is the single most important control on the page. It has two values. All users may self-authorize is the default, and it lets any user with the right API permission grant the app access to their data once they log in and approve the OAuth prompt. Admin approved users are pre-authorized flips that model. With it selected, only users who hold an assigned profile or permission set can use the app, and no consent prompt is shown to them. For anything beyond a personal productivity tool, the pre-authorized model is the safer default. It turns app access into an explicit grant that an admin manages, rather than a self-service action any user can take. After you switch to the pre-authorized mode, you assign access by adding profiles or permission sets to the app from the same management area. Keep that assigned set as small as the integration genuinely needs. A backend integration that runs as one service account does not need a profile covering hundreds of users. The narrower the assignment, the smaller the blast radius if the app's credentials are ever stolen or misused.
IP relaxation and how strictly ranges apply
Connected Apps respect the org's IP restrictions, but the page lets you decide how strictly. The IP Relaxation menu offers four choices. Enforce IP restrictions is the strictest and applies the IP ranges configured for the org, including ranges tied to a user's profile. Enforce IP restrictions, but relax for refresh tokens keeps those ranges for the initial login yet bypasses them when the app trades a refresh token for a new access token. Relax IP restrictions for activated devices lets a user bypass org ranges when the app uses the web server flow and the user has verified their identity on a new browser or device. Relax IP restrictions removes org IP enforcement for the app entirely. The right choice depends on the integration. A server-to-server partner integration running from known infrastructure can sit behind strict enforcement, sometimes paired with a Trusted IP Range set on the app itself. A mobile app used by field staff on changing networks usually cannot tolerate strict ranges, so a relaxed setting paired with strong user verification is the practical balance. Pick the tightest option the integration can actually live with.
Refresh token policy and session control
A refresh token lets an app keep working after its short-lived access token expires, without sending the user back through login. The page controls how long that convenience lasts through the Refresh Token Policy. Refresh token is valid until revoked is the most permissive and lets the app run indefinitely until someone cuts it off. Immediately expire refresh token effectively forces re-authorization every time the access token lapses. Expire refresh token if not used for a set period kills idle integrations while leaving active ones alone, and the clock resets each time the token is used. Expire refresh token after a fixed period sets a hard ceiling regardless of activity. The idle-expiry option is a good middle ground for many apps, because it cleans up integrations that quietly stopped running. The page also exposes session-level settings, including Single Logout. When enabled with an HTTPS logout URL, Single Logout signs a user out of the connected app when they log out of Salesforce, which keeps a closed Salesforce session from leaving a stray open session in the third-party app.
Monitoring and revoking through OAuth Usage
Editing policy is only half the job. The Connected Apps OAuth Usage page is the companion monitoring surface, reached from the same Connected Apps area in Setup. It lists the OAuth apps your users actually connect to, with a count of users for each. For apps that were never installed, it also records usage attempts that Salesforce automatically denied because of security restrictions, which is a useful early signal of something probing your org. Click a user count to open that app's usage detail, where you see when each user first used the app, the most recent time they used it, and how many times in total. Two revoke actions live here. Revoke ends one user's current session, and Revoke All ends every active session for the app at once. There is also a Block action that makes the app inaccessible to all users, ending current sessions and preventing new ones until you click Unblock. During a suspected compromise, Block plus Revoke All is the fast containment step. For routine hygiene, scanning this page surfaces apps that are still consuming sessions long after the project that needed them ended.
Treating consumer secrets as credentials
When you create a Connected App, Salesforce generates a consumer key and a consumer secret. The key is a public identifier for the app. The secret is the OAuth client secret the external app presents to prove it is the genuine app and not an impostor. That secret deserves the same care as a password. It should never sit in source control, never travel by email or chat, and never appear in a screenshot pasted into a ticket. Store it in a secrets manager or vault that your integration reads at runtime. If a consumer secret leaks, treat it as a security incident, not a cleanup task. Anyone holding both the key and the secret can attempt to authenticate as that app, so a leak means you rotate the secret from the Connected App detail and update every system that uses it. The page does not stop a careless secret from being copied somewhere unsafe, which is exactly why the operational discipline around it sits with the admin and the integration owner rather than with the platform.
Auditing apps and reducing standing risk
Connected Apps are easy to add and easy to forget. A team installs an app for a one-off migration, the project ends, and the app keeps its OAuth grant for years. Each lingering app is standing attack surface, especially if it holds broad scopes like full access or a refresh token that never expires. A regular audit, done quarterly for most orgs, keeps that surface from growing unchecked. Walk the Manage Connected Apps list and for each app ask three questions. Is it still in use, which the OAuth Usage page can confirm. Are its scopes the minimum the integration needs, or did it request full access when read-only would do. Is its permitted-users set as narrow as the work requires. Anything that fails a question gets tightened, blocked, or removed. Pair the review with a check of refresh token policies, because an app set to valid until revoked combined with broad scopes is the highest-risk pattern. The goal is simple. Every app that can reach your org should be one you can name, justify, and explain the access of.
Tighten a Connected App's OAuth policy
The most common task on this page is tightening an existing Connected App's OAuth policy. These steps configure who can use an app, how IP rules apply, and how long its refresh token lives.
- Open the page
From Setup, type Connected Apps in the Quick Find box and select Manage Connected Apps. The list shows every app installed in or created within the org.
- Edit the app's policies
Click Edit next to the target app, then Edit Policies. This opens the OAuth policy section where the access controls live.
- Restrict who can authorize it
Set Permitted Users to Admin approved users are pre-authorized for anything beyond a personal tool, then assign only the profiles or permission sets that genuinely need the app.
- Set IP and refresh token rules
Choose the IP Relaxation option the integration can tolerate, then pick a Refresh Token Policy. Idle expiry is a sensible default for most apps.
- Save and verify usage
Save the policies, then open Connected Apps OAuth Usage to confirm the app's active sessions still look correct and revoke anything unexpected.
All users may self-authorize (any user can grant access) or Admin approved users are pre-authorized (only assigned profiles or permission sets, no consent prompt).
Enforce IP restrictions; Enforce but relax for refresh tokens; Relax for activated devices; or Relax IP restrictions entirely.
Valid until revoked; immediately expire; expire if not used for a set period; or expire after a fixed period.
Optional. When enabled with an HTTPS logout URL, signs the user out of the connected app when they log out of Salesforce.
- All users may self-authorize is the default. Leaving it on means any API-enabled user can grant an app access to their data without admin involvement.
- The Manage Connected Apps page sets policy, but revoking live sessions happens on the separate Connected Apps OAuth Usage page.
- A refresh token policy of valid until revoked combined with broad scopes is the highest-risk pattern; prefer an expiry for sensitive integrations.
- Relaxing IP restrictions weakens a real control. Only loosen it for apps, like mobile clients, that genuinely cannot work behind fixed ranges.
Prefer this walkthrough as its own page? How to Manage Connected Apps in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Manage Connected Apps.
Hands-on resources to go deeper on Manage Connected Apps.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does each record on the Manage Connected Apps page represent?
Q2. On the Manage Connected Apps page, which permitted-users setting is the more secure choice?
Q3. When an integration tied to a Connected App is compromised, what is the containment step on this page?
Discussion
Loading discussion…