Connected Apps OAuth Usage
Connected Apps OAuth Usage is the Salesforce Setup page that surfaces operational visibility into OAuth-based access to the org: every Connected App that has authorized users, the count of users who have authorized each app, the count of active OAuth sessions per app, and the usage volume (API requests, total requests, error rates).
Definition
Connected Apps OAuth Usage is the Salesforce Setup page that surfaces operational visibility into OAuth-based access to the org: every Connected App that has authorized users, the count of users who have authorized each app, the count of active OAuth sessions per app, and the usage volume (API requests, total requests, error rates). The page is the audit and monitoring surface for any integration, mobile app, or third-party tool that authenticates to the org through OAuth.
Connected Apps OAuth Usage exists because OAuth proliferation is silent. Every app a user authorizes (Salesforce Mobile App, third-party tools, custom integrations, AppExchange products) creates an authorization persistent until revoked. Without visibility, orgs accumulate dozens of Connected Apps with active sessions from former users, unused apps, or compromised authorizations. The page is the visibility layer; the operational discipline around it (regular review, deauthorize unused, block compromised) is what turns visibility into security.
Why the Connected Apps OAuth Usage page is the OAuth security cockpit
Where the page lives and what it shows
Setup, Apps, Connected Apps, Connected Apps OAuth Usage. The page lists every Connected App with active OAuth authorizations: app name, user count, OAuth session count, API request count over the past 24 hours and 7 days, error rate. Click into an app to see per-user authorization details: which user authorized, when, scopes granted, last access time. The Block button immediately revokes all authorizations for the app; the Unblock button restores. The Edit button opens the Connected App definition for policy changes (IP restrictions, refresh token policies, scope changes).
Connected App vs Connected Apps OAuth Usage
The Connected App is the definition (the OAuth client configured for an integration). Connected Apps OAuth Usage is the runtime visibility surface. The definition lives in Setup, Apps, Connected Apps; the usage lives in the OAuth Usage page. The two are separate Setup destinations that work together: admins create the definition once, monitor usage continuously. The Connected App definition is also where policies (IP restrictions, permitted users, session timeout) are configured; the Usage page is where the effects of those policies are observed.
Authorization, refresh tokens, and the persistence model
When a user authorizes a Connected App, OAuth issues an access token (short-lived, typically 2 hours) and optionally a refresh token (long-lived, until explicitly revoked). The refresh token is what lets the integration keep accessing Salesforce without re-prompting the user. The refresh token persists in the user's authorizations until revoked through the OAuth Usage page, the user's Personal Settings, or session expiration on the Connected App policy. Refresh tokens are the silent compliance risk: a former employee's refresh token can persist for months until someone notices.
Common Connected Apps and what to look for
Typical Connected Apps in any org: Salesforce Mobile App (one per user authorization), Salesforce Inbox or Outlook integration, Salesforce CLI (Developer Hub, scratch orgs), Workbench, Postman or other API testing tools, third-party AppExchange products with OAuth access, custom integrations to ERPs, marketing automation, BI tools. Healthy orgs have dozens; unhealthy orgs have hundreds of stale apps. The signals to investigate: apps with high user count but low usage (potentially abandoned), apps with low user count but high usage (single integration with broad access), apps from unknown sources (potentially shadow IT).
Block and the emergency revoke pattern
The Block button on a Connected App immediately revokes all OAuth authorizations for that app across every user. This is the emergency response when a Connected App is compromised, when a vendor relationship ends, when the security team detects suspicious behavior. Block takes effect within minutes; subsequent API calls from that Connected App fail with authentication errors. The unblock path is symmetric; users will need to re-authorize. For coordinated revoke without disruption, prefer scope change or IP restriction over Block.
Per-user deauthorization vs per-app block
The per-user authorization detail shows individual user grants. Revoking one user's authorization affects only that user; the Connected App remains active for others. This is the right tool for offboarding (deauthorize the leaver's Salesforce Mobile App authorization, for instance) without disrupting active users. Most offboarding workflows include deauthorizing Connected Apps as a checklist item; without it, the leaver's mobile authorization persists and is a security gap until the OAuth session times out, which may be never if a refresh token is in use.
Monitoring patterns and the operational discipline
Most orgs underuse the Connected Apps OAuth Usage page. The page is checked during incidents but rarely as routine. The discipline that pays off: monthly review of the list, deauthorize unused apps and stale user authorizations, investigate apps with surprising volume, document the active inventory. For larger orgs, build a report on the OauthToken object that surfaces stale authorizations (no use in 90 days, refresh token still active) so the monthly review starts with a prioritized list rather than reading every row.
How to run a Connected Apps OAuth review that catches real risk
The pattern: monthly review of the OAuth Usage page, monthly investigation of anomalies, quarterly audit aligned with offboarding records. The cost is a few hours per month; the security and compliance benefit compounds over years.
- Open the OAuth Usage page monthly
Setup, Apps, Connected Apps, Connected Apps OAuth Usage. Pull the list. Note total app count and any new apps since last review.
- Investigate new apps appearing since last review
For each new app, confirm: who installed or authorized it, what integration does it serve, who owns it. Apps from unknown sources are shadow-IT signals.
- Flag apps with high user count but low usage
Potentially abandoned. Confirm the integration is still needed; deauthorize at the app or per-user level if not.
- Flag apps with low user count but high usage
Single integration with broad access; the user typically belongs to a service account. Confirm the service account is still needed.
- Cross-check against the offboarding list
For users deactivated in the past 90 days, check their authorizations on the OAuth Usage page. Deauthorize any remaining; offboarding leaks are the most common compliance gap.
- Document the active inventory
List of expected Connected Apps with owner and purpose. Apps not on the list need investigation; the inventory is the change-control baseline.
- Schedule a quarterly deeper audit
Quarterly, build a report on OauthToken for stale authorizations (no use in 90 days). The report is the prioritized list for the deeper review.
Block revokes all authorizations for an app; per-user revoke affects only one user. Pick based on scope.
Monthly review for most orgs; weekly for high-security or high-volume integrations.
The team-maintained registry of expected Connected Apps with owner and purpose.
Report on OauthToken filtering for no use in 90 days; the prioritized list for deeper review.
Whether user deactivation triggers automatic deauthorization. Manual cross-check is the fallback.
- Refresh tokens persist until revoked. Deactivating a user does not automatically revoke their OAuth authorizations; manual cleanup is required.
- Block is immediate and broad. It revokes for every user; coordinate before clicking on any production-relevant Connected App.
- Apps from unknown sources are often shadow IT. Investigate the source before deauthorizing; the legitimate path may exist.
- High user count and low usage often signals an abandoned integration. Deauthorize if confirmed unused; the apps clutter the visibility surface.
- Quarterly audit catches gaps the monthly review misses. The OauthToken report surfaces stale authorizations the page summary does not highlight.
Trust & references
Cross-checked against the following references.
- OAuth Usage referenceSalesforce
- Salesforce security overviewSalesforce
Straight from the source - Salesforce's reference material on Connected Apps OAuth Usage.
- Connected Apps OAuth UsageSalesforce Help
- Connected Apps OverviewSalesforce Help
- Manage Connected AppsSalesforce Help
Hands-on resources to go deeper on Connected Apps OAuth Usage.
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. Why is understanding Connected Apps OAuth Usage important for Salesforce admins?
Q2. In which area of Salesforce would you typically find Connected Apps OAuth Usage?
Q3. What is the primary benefit of Connected Apps OAuth Usage for Salesforce administrators?
Discussion
Loading discussion…