Salesforce Connected Apps: Navigating NHI Security Risks and Best Practices

Salesforce security sits in this weird no-man's-land. It's not clearly IT's job, not entirely the security team's responsibility, and sometimes falls partly on the Sales Ops roles in the business units themselves. Figuring out who truly "owns" permission management can turn into a serious headache.

In Salesforce, user identities primarily are a single user type, which can represent both human users and automated accounts (often referred to as service accounts). Today, our focus will specifically address scenarios involving users that function explicitly as service accounts, or in our terms, non-human identities.

Connected Apps: Essential but Risky Gateways

Connected Apps in Salesforce allow external tools: marketing apps, third-party integrations, or external systems - to interact with your Salesforce environment.

These apps commonly use authentication methods like OAuth, SAML, or OpenID Connect. OAuth lets an external app act on behalf of a Salesforce user, granting access limited strictly by defined scopes. SAML and OpenID Connect offer single sign-on (SSO), simplifying user login across multiple apps.

Think of connected apps like hotel key cards. Your card grants you access to specific rooms - maybe your own room, the gym, or the pool-but it definitely doesn't unlock every room in the hotel. Similarly, connected apps should have tightly controlled permissions, only granting external systems precisely what they need to perform their functions.

For example, if your business uses a marketing automation app, you'd set up a connected app with a dedicated Salesforce identity, giving it just enough permissions to manage leads-but nothing beyond that.

Before we dive deeper into a surprisingly common scenario with OAuth applications working on behalf of individual users, let's first break down essential part - how permissions and profiles work in Salesforce.

Salesforce's Permission Model: Profiles vs. Permission Sets

Permissions in Salesforce are structured in layers, making it easy (at least in theory) to control who can do what. First off, we have Profiles. These are mandatory - you literally cannot create a user without assigning them one. Profiles set the baseline permissions - think of them as a basic job description, clearly outlining what a person can and cannot access.

But jobs evolve, right? Salesforce addresses this with Permission Sets, which you can add on top of a profile (Salesforce operates on a "grant-only" model, meaning permissions are explicitly granted rather than denied). Permission sets are essentially extra keys you hand out when someone needs just a bit more access, but not enough to warrant changing their entire profile.

Now that we understand how granting privileges works in Salesforce, it's time to talk business.

Hidden Risk: Single User Identity, Multiple Connected Apps

A common but risky practice is using a single Salesforce user for multiple connected apps.Initially, it seems convenient: fewer accounts, less management hassle. But there's a hidden danger here. That single user ends up accumulating excessive permissions to satisfy all those apps needs.

This diagram shows multiple Connected Apps (Power BI, DocuSign) using a single Integration User with a minimal-access profile. While each app has a dedicated permission set for its needs, they all share the same salesforce user - so, in practice, each connected app can leverage any permission granted to that user. The sum of the profile plus all assigned permission sets determines the user’s (and thus the apps) effective access in Salesforce.

The result? You've inadvertently created a privileged user an attractive target. If compromised, attackers potentially gain widespread access to your Salesforce environment.

Best Practices to Mitigate This Risk

• Dedicated Integration Users: Create specific Salesforce identities for each integration or app. Although it means upfront work, it drastically reduces security risks.
• Least Privilege Principle: Only provide permissions necessary for each integration. The less access granted, the safer your data.
• Regular Monitoring: Regularly review your OAuth and API logs. Salesforce provides built-in monitoring tools to easily detect unusual behavior.

Another bad practice, more common than I ever imagined - is misusing the permission model. Wait till you hear about it… you might even call it ridiculous.

The Absurdity of Granular Permission Sets Combined with a High-Level Profile

We’re really up against two core issues:

It's like installing high-security locks on your front door, but leaving your garage wide open. Let me illustrate this:

Suppose a developer needs limited access, like deploying code changes. Your admin carefully designs a permission set with just the right deployment permissions-but then inexplicably assigns it to a user who has the System Administrator profile. Even if your admin designed a least privilege permission set, it doesn’t matter because he already assigned the user with a base profile that has System Administrator privileges.

Two real customer examples of permission & profiles misconfigurations

Mitigating the Risk: A Strategic Approach

To avoid the pitfalls of over-permissive profiles:

1. Start with minimal baseline access using profiles tailored to specific roles.
2. Layer on precise permissions using granular permission sets for specific tasks.
3. Regularly audit and adjust permissions to maintain alignment with evolving user needs and security standards.

On the left, a System Administrator profile bundles all sorts of powerful abilities-from managing users to handling invoices-whether they’re needed or not. On the right, a strictly limited base profile grants only essential privileges, with extra permissions (like importing leads) added individually. This smaller, more tailored set of permissions reduces security risks and makes day-to-day management far more practical.

Bottom line? Keep it lean, keep it watched.

Stick to least-privilege, start every user (human or non-human) with a bare-bones profile, and keep a close watch on integration users. Managing Salesforce security might not be the flashiest part of your day but getting it right matters.Because, let’s face it - cleaning up after a messy permissions party isn't fun for anyone.

Permission chaos and runaway connected apps? Let’s talk about how Token Security can elevate your Salesforce security. 🚀

‍