Connected User
A Connected User in Salesforce is a user record that has authorized access to one or more Connected Apps through OAuth, meaning the user has explicitly granted an external application (mobile app, integration tool, third-party service) permission to act on their behalf in the org.
Definition
A Connected User in Salesforce is a user record that has authorized access to one or more Connected Apps through OAuth, meaning the user has explicitly granted an external application (mobile app, integration tool, third-party service) permission to act on their behalf in the org. The connection persists until the user revokes the authorization, the admin blocks the Connected App, or the OAuth session expires per the configured token lifetime. Connected Users are visible per-Connected-App in the OAuth Usage page and per-user in the user's Personal Settings.
The term shows up most often in two contexts: security audits (which users have connected which apps, and are any of those connections stale or compromised) and offboarding (when a user leaves, every Connected User authorization they held needs explicit revocation, because user deactivation does not automatically revoke OAuth tokens). Connected User management is one of the underappreciated security disciplines in mature orgs; the authorizations accumulate silently and become liabilities when not actively pruned.
Why every Connected User authorization deserves explicit lifecycle management
Where Connected User information surfaces
Connected User data appears in two main places. Setup, Apps, Connected Apps, Connected Apps OAuth Usage shows the per-app view: every Connected App with active authorizations, the user count per app, and a drill-down to per-user details. The user's Personal Settings, OAuth Connected Apps shows the per-user view: every app the user has authorized, when, and with what scopes. Both views write to the same underlying data (the OauthToken object) but present it from different angles. The OauthToken object is queryable via SOQL for custom reporting.
The OAuth authorization flow that creates a Connected User
A user becomes a Connected User the first time they authorize a Connected App. Common flow: the user opens the third-party app, the app redirects to Salesforce login (if not logged in) and to an OAuth consent screen, the user reviews the requested scopes (Access your data, Manage your data, Access your basic information), the user clicks Allow, Salesforce issues an access token and a refresh token, the third-party app stores the refresh token, the user is now a Connected User for that app. The authorization persists until explicit revocation.
Scopes and what the Connected User actually granted
Scopes are the granular permissions the user grants. Common scopes: api (general API access), full (read and write everything the user can see), refresh_token (let the app refresh the token), web (web-based redirects), chatter_api (Chatter-specific access), custom_permissions (custom permissions in the app), openid (OpenID Connect identity). The scopes determine what the app can do; full is the most permissive and most common for trusted integrations. Some apps request narrower scopes by default; the Connected User can review scopes on each authorization but rarely does in practice.
Refresh tokens and the persistence question
When the Connected App is configured for refresh token issuance, the user's authorization persists indefinitely until explicit revocation. The access token expires (typically 2 hours) and the app uses the refresh token to get a new one without user interaction. This is convenient (users do not re-prompt every 2 hours) and silent (the user does not see the refresh happening). The persistence is also the security risk; a refresh token from a former employee can keep the third-party app accessing data months after the employee left, unless the authorization is explicitly revoked.
Connected User and user deactivation
Deactivating a user in Salesforce does not automatically revoke their Connected User authorizations. The OAuth tokens remain valid for the lifetime of the refresh token policy on each Connected App. Some Connected Apps refresh-token-revoke on user deactivation; many do not. The safe pattern: include explicit deauthorization of every Connected App in the offboarding checklist. Pull the OauthToken records for the leaver and revoke each. The compliance gap from skipping this step is silent and can persist for months.
Per-user revocation vs per-app block
Two revocation paths. Per-user revocation removes a single user's authorization for a single app (or all apps for that user); other users keep their authorizations intact. The per-user path is the right tool for offboarding (revoke the leaver's authorizations without affecting active users). Per-app block (the Block button on the Connected App in OAuth Usage) revokes every user's authorization for the app at once; the right tool for compromised vendors, ended partnerships, security incidents. Pick based on scope and urgency.
Audit and the quarterly cleanup discipline
Connected User authorizations accumulate. A user who tried a third-party tool once five years ago may still have an active authorization. A former service-account user's authorizations may persist across the platform. The quarterly audit: pull OauthToken records, filter for last-used dates over 90 days ago, review whether each is still needed, revoke the stale ones. Most orgs find dozens to hundreds of stale authorizations during the first audit; subsequent quarterly audits catch new accumulation before it grows.
How to manage Connected User authorizations as part of security operations
The pattern: monitor monthly via OAuth Usage, revoke per-user on offboarding, revoke per-app on incidents, audit quarterly for stale authorizations. The discipline turns a silent accumulation into a controlled inventory.
- Review OAuth Usage monthly
Setup, Apps, Connected Apps, Connected Apps OAuth Usage. Note new apps and apps with unexpected user counts. Investigate anomalies.
- Build OauthToken stale-authorization report
Report on OauthToken filtering for LastUsedDate over 90 days ago. The report is the prioritized list for the quarterly deeper audit.
- Add Connected User revocation to offboarding checklist
Every leaver gets their authorizations explicitly revoked. Query OauthToken WHERE UserId = leaver, revoke each row.
- Document expected Connected App inventory
Per app: owner team, business purpose, expected user population. Apps outside the inventory need investigation.
- Configure refresh token lifetime policy per Connected App
Shorter lifetimes reduce the silent-persistence risk at the cost of more frequent re-prompts. Tune per app sensitivity.
- Train users on revoking authorizations they no longer need
Personal Settings, OAuth Connected Apps. Users who try a tool and abandon it should revoke; few do without training.
- Run the quarterly audit on the stale-authorization report
Review each stale authorization, decide whether to revoke, document. The audit produces the compliance evidence regulators want.
Removes one user's authorization for one app. Right tool for offboarding.
Revokes every user's authorization for one app at once. Right tool for compromised or ended apps.
Per-Connected-App policy that bounds how long an authorization persists. Tune for sensitivity.
Monthly OAuth Usage review plus quarterly stale-authorization audit. The combination catches both new anomalies and accumulated drift.
Documented list of expected apps with owner and purpose. The baseline against which the OAuth Usage view is reviewed.
- User deactivation does not revoke Connected User authorizations. Manual revocation as part of offboarding is the only reliable cleanup.
- Refresh tokens persist indefinitely by default. Connected App refresh token policy bounds the persistence; without policy, authorizations can live for years.
- Stale authorizations accumulate silently. Quarterly audit on the OauthToken report is the only reliable surfacing mechanism.
- Per-app block is immediate and broad. Confirm scope before clicking on production-critical apps.
- Scopes granted by the user may be broader than the third-party app actually needs. Audit Connected App scopes during onboarding to confirm least-privilege.
Trust & references
Cross-checked against the following references.
- Connected Apps referenceSalesforce
- Salesforce security overviewSalesforce
Straight from the source - Salesforce's reference material on Connected User.
- Connected Apps OAuth UsageSalesforce Help
- OAuth EndpointsSalesforce Developers
- Deactivate UsersSalesforce Help
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 is a Connected User?
Q2. Where do admins manage Connected User sessions?
Q3. When should you revoke a Connected User's tokens?
Discussion
Loading discussion…