How to Audit Salesforce Connected Apps (3 Methods)

On 20 August 2025, Salesloft and Salesforce revoked every active access and refresh token for the Drift app, according to the Google Threat Intelligence Group’s report on data theft from Salesforce instances through Salesloft Drift. Each token was a grant from one Salesforce user to one outside app. A review of profiles and permission sets doesn’t show grants like that.

Salesforce connected apps build up the same quiet way, one user authorization at a time, until nobody can say which tools still reach the org. Auditing them means tracing each live token back to the person who granted it and checking whether that person is still active.

Three methods cover that audit, starting with the Connected Apps OAuth Usage page that every Salesforce admin already has in Setup. Torii then matches each app to the users holding its tokens and checks their Salesforce status, and the Salesforce REST API exports every grant as a check you can schedule.

What Are Salesforce Connected Apps?

A connected app is the record Salesforce keeps for an external application that reaches your org through OAuth, such as a calendar sync or a sales engagement tool. Every person who approves that app gets an OAuth token, a grant tied to that one user and that one app. Salesforce third-party apps can also arrive as AppExchange packages, which install components inside the org, and a package can bring a connected app with it.

An audit of Salesforce connected apps is really an audit of the OAuth tokens behind them, since tokens are what Setup tracks. Salesforce Help describes the inventory page as listing every app users are connected to with a live token, including apps that aren’t installed in the org.

Salesforce has changed the rules for these apps in the past year, first in September 2025 and again with the Spring ‘26 release. Since September 2025, most users are blocked from connected apps that aren’t installed in the org, unless they hold the Approve Uninstalled Connected Apps or Use Any API Client permission (Salesforce Admins blog).

Spring ‘26 then turned off new connected app creation by default in the UI and the Metadata API, and made external client apps the primary way to define inbound integrations. Existing connected apps keep working. The Salesforce Architects blog tells admins what to do about the ones they have: “Plan a formal audit and inventory for existing Connected Apps for your eventual migration.”

Source: Salesforce Help, Monitor Usage for an OAuth Connected App; Salesforce Admins blog, September 2025; Salesforce Architects blog, Spring ‘26 highlights, February 2026.

Use Salesforce’s Connected Apps OAuth Usage Page

A one-time audit in Setup runs across four pages, from the inventory to the people behind each app to its policies, then the same check for external client apps.

Source: Salesforce Help, Monitor Usage for an OAuth Connected App, Manage Current OAuth Connected App Sessions, and Manage Access to a Connected App; Salesforce blog, February 2026.

1. Open Connected Apps OAuth Usage in Setup

Sign in as a Salesforce admin, open Setup, type “connected app” in Quick Find, and choose Connected Apps OAuth Usage, the same path Trailhead uses. Per Salesforce Help, the page lists each OAuth app that users hold live tokens for, with a User Count beside each one.

2. Flag apps that show an Install action

An Install action next to an app means people are using it while the org has no local copy, so you can’t set policies for it. Installing it brings its policies into your org, and from there you can control who uses it.

3. Open User Count to see who uses each app

Clicking an app’s User Count opens Connected App User’s Usage, which lists each user with their first use, most recent use, and use count.

4. Revoke tokens for people who shouldn’t have them

On the same usage page, Revoke ends one user’s access to the app and Revoke All logs out everyone using it. Start with people who changed roles and anyone whose Most Recent Use date falls before your last access review.

5. Block apps you don’t recognize

Back on Connected Apps OAuth Usage, Block ends every current session with an app and stops new ones, and Unblock reverses it if a team turns out to need the tool. Leave Uninstall out of this step. It removes only the local copy installed to set policies, so users keep their access.

6. Tighten policies in Manage Connected Apps

For the apps you keep, open Manage Connected Apps, select the app, and choose Edit Policies, where its OAuth and session policies sit next to its profiles and permission sets. Permitted Users has the most reach of those settings, and Salesforce’s inbound governance post covers it in its advice for hardening installed connected apps:

“Access : Set Permitted Users to “Admin approved users are pre-authorized”. This removes the ability for users to self-authorize and requires you to explicitly grant access via Permission Sets.”

The switch cuts off anyone who doesn’t reach the app through a profile or permission set. Assign those before saving. Users with Use Any API Client bypass the setting entirely.

7. Repeat on External Client Apps OAuth Usage

External client apps have a separate page, External Client Apps OAuth Usage, which lists their tokens and lets you revoke a single token, all of one user’s tokens, or all access to the app. New inbound integrations are defined as external client apps since Spring ‘26, so this list will grow.

Steps 3 and 4 depend on knowing which users have left or gone inactive, and Setup leaves that cross-check to you, one app at a time.

Use Torii to Match Connected Apps to Active Users

Torii’s Salesforce connector reads the third-party apps your users have authorized over OAuth and lists each app’s token holders, along with each user’s Salesforce status.

1. Request a Torii proof of concept

Request Torii’s free two-week proof of concept, which sets up the Torii account you’ll connect Salesforce to.

2. Connect Salesforce

In Torii, open the Integrations page, find Salesforce, click Connect, and authorize over OAuth as a user with View Setup and Configuration (plus View All Users if your Users sharing default is Private). Choose Read-Only, or Read/Take Action if you want workflow actions. The Salesforce integration help article has the full setup.

3. Review Salesforce-connected apps in Torii

Apps that Salesforce reports as connected over OAuth show up on Torii’s Applications page, with Salesforce listed in the Sources column of the Review tab. The connector brings in OAuth-connected apps only. Torii’s help article notes that this data may be partial. The Salesforce integration page lists everything else the connector reads.

Open an app’s Users tab to see who authorized it, since the tab lists the Salesforce users holding OAuth tokens for that app. Next to each person, Torii’s Usage column counts the days they used the app in the past 30 days (per Torii Help), with a last used date beside it. Each user’s Salesforce status, role, and profile name come in through the same connector, so a token holder who has been deactivated or moved roles stands out across Torii’s SaaS visibility.

Torii highlights apps used by offboarded users, because a person who left may still have an account in the app. To retire an app, set its state to Closed in Torii. If Salesforce reports someone using it after the next sync, the Closed app in use trigger fires and runs whatever workflow you attach to it.

Revoking the token still happens in Salesforce Setup (step 4 above), after which Torii gets no more usage for that app from Salesforce. When the person who authorized an app has left, an offboarding workflow can run the Deactivate Salesforce user action, the automated version of deactivating users in Salesforce. Torii’s 2026 SaaS Benchmark report found that about 2.5% of seats in paid apps are still assigned to people who have left the company (data from January to December 2025).

For a softer step, the Freeze Salesforce user action matches freezing a Salesforce user by hand.

Use the Salesforce REST API and SOQL

The REST API turns the audit into an export you can schedule. This method stays read-only, so revocation goes back to Setup. Every connected app grant sits in the OauthToken object, which SOQL can query like any other object, while external client app tokens stay on their own OAuth Usage page (step 7 above).

1. Get a token from an existing integration user

Authenticate as an integration user you already run, through an external client app, instead of creating a new connected app for the script (new connected apps are off by default since Spring ‘26, as above).

2. Query OauthToken for every connected app grant

The OauthToken object exposes AppName, UserId, LastUsedDate, UseCount, CreatedDate, and AppMenuItemId to SOQL. SalesforceBen’s audit guide starts from that query, though the January 2025 guide predates the September 2025 and Spring ‘26 changes.

3. Add each token owner’s status

Extend that query with User.Name and User.IsActive through the UserId relationship, and any token still listed for a deactivated user comes back with IsActive set to false. Revoke those rows in Setup.

4. Call the query endpoint and page through results

The Salesforce REST API Developer Guide has you send the URL-encoded SOQL to /services/data/v{version}/query on your My Domain, with a Bearer token in the Authorization header. The JSON response carries totalSize, done, and records, plus a nextRecordsUrl whenever more rows remain, so keep calling it until it disappears. The same pattern drives the license queries in monitoring Salesforce license usage.

5. Split large orgs by user

A SOQL query on OauthToken returns at most 2,500 rows, per Salesforce’s OauthToken object reference, so a larger org has to split the query by UserId and combine the results.

6. List apps still open to self-authorization

The read-only ConnectedApplication object carries an OptionsAllowAdminApprovedUsersOnly field, and querying it shows which apps any user can still authorize alone. Apps still showing an Install action in Setup aren’t in this object, so install them first (step 2 of the Setup method). To stop new grants across the org, SalesforceBen (January 2025) points to API Access Control, which Salesforce Support enables to allowlist approved connected apps and block the rest.

# Read-only queries. Needs curl and jq.
export SF_TOKEN="access-token-from-your-integration-user"
export SF_URL="https://yourdomain.my.salesforce.com"
export SF_VERSION="vXX.X"   # your org's current API version

# 1. Every connected app OAuth grant, with the token owner's name and status
curl -s -G "$SF_URL/services/data/$SF_VERSION/query" \
  -H "Authorization: Bearer $SF_TOKEN" \
  --data-urlencode "q=SELECT Id, AppName, UserId, User.Name, User.IsActive, CreatedDate, LastUsedDate, UseCount FROM OauthToken ORDER BY AppName" \
  > tokens-page-1.json

# Tokens held by deactivated users
jq '.records[] | select(.User.IsActive == false) | {AppName, user: .User.Name, LastUsedDate}' tokens-page-1.json

# 2. Next page, while nextRecordsUrl is present
NEXT_URL=$(jq -r '.nextRecordsUrl // empty' tokens-page-1.json)
[ -n "$NEXT_URL" ] && curl -s "$SF_URL$NEXT_URL" -H "Authorization: Bearer $SF_TOKEN" > tokens-page-2.json

# 3. Past the row cap, split by user: add WHERE UserId IN ('005...', '005...') to the query above

# 4. Connected apps and whether only admin-approved users can use them
curl -s -G "$SF_URL/services/data/$SF_VERSION/query" \
  -H "Authorization: Bearer $SF_TOKEN" \
  --data-urlencode "q=SELECT Id, Name, OptionsAllowAdminApprovedUsersOnly FROM ConnectedApplication" \
  | jq '.records[] | select(.OptionsAllowAdminApprovedUsersOnly == false) | .Name'

After an incident like the Drift token revocation, start in Setup and block any app nobody on the team recognizes. Then script the OauthToken query so later reviews repeat the same checks on a schedule, and bring in Torii when IT wants every grant matched to its holder’s Salesforce status without a manual cross-check. For the wider question of who holds which Salesforce permissions, compare these Salesforce access review tools.