salesforce has thirty connected apps you can't name

A VP of Revenue Operations at a B2B SaaS company ran an audit of her Salesforce org in mid-2025. The audit was supposed to be about data hygiene, duplicate records, stale leads, incomplete fields. Her team had been preparing for a major migration and wanted a clean baseline.

In the course of the audit, she clicked through to the “Connected Apps” section of the Salesforce admin console. The section listed 47 connected applications. She recognized seven of them. She roughly recognized another dozen. The remaining 28 were applications she had never seen before, with names she didn’t recognize, granted to her org sometime in the last six years by someone she couldn’t identify.

Each of those connected apps had OAuth scopes. Most of them had read access to accounts, contacts, and opportunities. A meaningful fraction had read-write access. A few had administrative-level access, granted by whoever had originally authorized them.

The VP escalated to her CISO. The CISO’s team investigated. The investigation found that 22 of the 28 mystery apps could be traced to ex-employees, people who had installed the app for a trial, granted access, and left the company. The apps continued to hold active OAuth grants against the Salesforce org, with tokens that had been refreshing every time the apps made a call. Six of the apps couldn’t be traced to any current or former employee, and the origin of the authorization remained unknown.

The Salesforce org had been operating as an identity provider for these 47 third-party applications, without the CISO’s team knowing the list, without any access review covering the applications, and without any revocation of OAuth grants from departed employees.

This pattern is not specific to Salesforce. Every major SaaS platform with an app marketplace, Slack, Google Workspace, Microsoft 365, GitHub, HubSpot, Atlassian, has the same architecture. A third-party application gets installed by a user. The user grants OAuth scopes. The application now has standing access to the data that user can see. The installation persists long after the user is gone.

This essay is about that pattern. How these installations happen, why they accumulate, what they give access to, and how to bring them back into the identity perimeter.

the connected app is an identity provider

The core mechanic is straightforward. A third-party application wants to access your SaaS data. The application implements OAuth against the SaaS platform. A user logs into the third-party application and is prompted to authorize access. The user reviews the scopes (usually without reading them carefully), clicks authorize, and the application is now configured.

Behind the scenes, the SaaS platform stores an OAuth grant. The grant specifies which application, which user granted it, which scopes were authorized, and the tokens associated with the grant. The application can now make API calls to the SaaS platform on behalf of that user, within the scopes granted, as long as the tokens remain valid.

The grant persists. The application, if it’s well-behaved, will refresh its tokens periodically to maintain access. If it’s not well-behaved, or if it’s malicious, the long-lived nature of the grant means the access continues until somebody notices.

The critical property of this arrangement is that the SaaS platform, in granting the OAuth scope, is functioning as an identity provider for the third-party application. The third-party application doesn’t need to know the user’s password. It doesn’t need to know the user’s primary identity. It needs only the tokens from the SaaS platform, and the SaaS platform will vouch for the user’s identity every time the application checks.

This shadow identity relationship exists outside your primary IdP’s view. Okta doesn’t know about the Salesforce OAuth grants. Entra doesn’t know about the Slack app installations. Google Workspace’s admin console knows about Google OAuth grants, but not about the separate OAuth relationships inside, say, HubSpot.

Each SaaS platform maintains its own OAuth grant table, its own list of connected apps, its own audit log of who granted what. These lists are rarely consolidated anywhere. They are rarely reviewed. They accumulate.

the trial-install-forget pattern

1. 1install a trialSomeone connects an app to try a feature.
2. 2grant scopesThe app asks for broad access, and gets it.
3. 3the trial endsNobody uninstalls it, because nothing reminds them.
4. 4the grant keeps workingThe app can still read and write data it no longer needs.

the marketplace encourages installation

Every major SaaS platform has a marketplace. Salesforce has AppExchange. Slack has its app directory. Google has the Workspace Marketplace. Microsoft has AppSource. HubSpot has its integrations directory. Each marketplace is designed to make it easy for users to discover and install third-party applications.

The marketplace model is valuable. It creates an ecosystem around the platform. It increases the platform’s utility. It makes users more productive.

It also bypasses IT. A user browsing the Salesforce AppExchange can install a connected app with three clicks. The install flow doesn’t require approval from a central administrator. The user’s own permissions authorize the app. If the user is a Salesforce admin, the install happens at the org level. If the user is a standard user, the install happens at the user level, but the app still gets a valid grant.

This is intentional design. The platform wants installations to be frictionless. Friction would reduce installations, which would reduce the ecosystem’s vitality. The platform’s monetization depends on a thriving marketplace.

The side effect, from your IT team’s perspective, is that every employee with a Salesforce login is now a provisioning authority. Every install they perform grants third-party access to your data. Your IT team is not in the loop for any of these decisions.

Multiplied across your user base and the marketplace’s scale, the result is a sprawl of third-party integrations that nobody at your company has reviewed. The Salesforce admin console shows the list. Nobody looks at the list.

the trial-install-forget pattern

The typical installation is not malicious. It is also not permanent-by-design. It’s a trial.

An employee hears about a new tool that integrates with Salesforce. Maybe it’s a sales engagement tool, a data enrichment service, a meeting scheduler, an analytics dashboard. The employee signs up for a free trial. The trial requires OAuth authorization to Salesforce. The employee clicks authorize.

The employee evaluates the tool for two weeks. Maybe they like it, maybe they don’t. If they don’t, they stop using the tool. They do not uninstall the app from Salesforce. They do not revoke the OAuth grant. They just stop logging into the tool.

The tool, on its side, keeps its valid OAuth grant. Some tools actively use the grant (for example, running periodic data syncs even when the user is inactive). Some tools sit dormant with the grant unused. Either way, the grant remains valid until explicitly revoked.

Six months later, the employee has forgotten the trial happened. A year later, the trial service may have been acquired, pivoted, or shut down. The underlying OAuth grant, pointing at whatever the trial service has become, is still there.

Aggregate this across every trial every employee has ever started. The Salesforce Connected Apps list is a graveyard of trials. Same for every other major SaaS platform.

scope review is the missing governance

The OAuth scope is the actual governance mechanism, and it’s the one least exercised.

When a user authorizes a third-party application, they are presented with a list of scopes. “Read your accounts.” “Write to your contacts.” “Read and write all opportunities.” “Access your organization’s configuration.” The user clicks authorize.

The scopes are often broader than the application strictly needs. An application that only needs to read basic contact information may request access to all fields on all objects, because the broader scope is easier to configure and reduces development friction. Users rarely read the scope list carefully. They click authorize because they want the app to work.

The consequence is that a typical connected app has more permissions than it actually uses. If the application is ever compromised, if its developer’s credentials are leaked, if the application is bought by a bad actor, if a rogue employee at the vendor decides to misuse the access, the compromised scope is the full requested scope, not the actual-usage scope.

Scope review is what should happen at install time and at periodic intervals afterward. Review what the app actually does. Compare to the scopes granted. Reduce scopes where possible. Uninstall where the app is no longer used.

Scope review does not happen in practice at most companies. It doesn’t happen at install time because the user clicks through. It doesn’t happen later because nobody has a workflow for periodic review of connected apps. The scopes sit at install-time maximum, forever.

the high-privilege connections

A specific subcategory worth isolating: connected apps with administrative scope.

When a Salesforce admin (or the equivalent role in any platform) authorizes a connected app, the app often gets access to everything the admin can see. In Salesforce, that’s potentially every record, every field, every customization, every user, every configuration.

Admin-authorized connected apps are the highest-stakes OAuth grants in your environment. They sit behind the same kind of privilege as your most privileged employees, accessible through a credential that exists outside your primary identity system.

Examples of admin-authorized connected apps in the Salesforce ecosystem: data migration tools, backup tools, integration platforms, comprehensive analytics tools, security tools. Each of these legitimately needs broad access to function. Each of them, if compromised, has broad access to your CRM.

The same pattern exists in Microsoft 365 with admin-granted Graph API permissions, in GitHub with GitHub Apps installed at the org level with admin consent, in Google Workspace with service accounts impersonating users.

The admin-authorized grants should be the most carefully managed subset of your OAuth inventory. In practice, they are often the least managed, because the admin who authorized the grant has moved on, the tool has been replaced by a successor tool without the original being revoked, or the vendor of the tool has been acquired by a company the admin has never heard of.

the inventory you can pull

Every major SaaS platform exposes its connected apps or OAuth grants through the admin console and, usually, through an admin API.

Salesforce: Setup → Apps → Connected Apps → Manage Connected Apps. The list shows each installed app, the users who have granted access, and the permitted scopes. Programmatically, the list is available via the ConnectedApplication and OauthToken objects.

Slack: Admin → Manage Apps → Installed. Shows each installed app and (for paid plans) the installer. Programmatic access through admin.apps.list.

Microsoft 365: Entra admin → Enterprise applications → All applications. Shows each app registered in the tenant, its permissions, and its last activity. Programmatic access through Graph API.

Google Workspace: Admin Console → Security → API Controls → Domain-wide delegation and Third-party app access. Shows apps with either user-granted or admin-granted access.

GitHub: Settings → Applications → Installed GitHub Apps and Authorized OAuth Apps. At the org level, requires org admin. Shows each app and the permissions it holds.

HubSpot: Settings → Integrations → Connected Apps. Shows integrations and their scopes.

The inventory exercise is to pull this list from each of your major SaaS platforms, consolidate into one spreadsheet, and review.

The review asks, for each entry: do we still use this? Who installed it? Is the installer still with the company? Are the scopes appropriate? What data does this app actually touch?

For apps that are no longer used, uninstall. For apps installed by ex-employees, uninstall and reinstall under a current employee if still needed. For apps with excessive scopes, reduce the scopes or uninstall and find an alternative.

the specific exercise

Run this the same week you read this.

Pick your top five SaaS platforms by data sensitivity, the ones that hold customer data, employee data, financial data, or intellectual property. Likely candidates: Salesforce, Microsoft 365 or Google Workspace, Slack, GitHub, your identity provider, your data warehouse, your cloud provider.

For each of the five, pull the list of connected apps, integrations, or OAuth grants. Depending on the platform, this takes between five minutes and an hour.

Put all five lists in a spreadsheet. Include: application name, installer (or original grantor), last-activity date, granted scopes.

Sort by last-activity date, oldest first. Everything that hasn’t had activity in ninety days is a candidate for removal. Everything granted by someone no longer at the company is a candidate for removal. Everything with scopes exceeding current use is a candidate for scope reduction.

Start uninstalling. Start revoking. Start reducing scopes.

The first pass will surprise you with how much cleanup is available. The subsequent quarterly passes will keep the inventory clean.

Your CRM has thirty connected apps you didn’t know about. Your Slack has twice that. Your Google Workspace has hundreds of OAuth grants across your user base. Each of those grants is a standing identity arrangement that your identity provider has no visibility into.

The admin consoles have the lists. The lists have been there the whole time. The review has not happened because no one’s job description includes it. Add it to someone’s job description. Add it to yours if you have to.

The apps you can’t name are the ones with grants you can’t defend.