‘What Can I Do Today?’ A CEO’s Guide to Salesforce Integration Security

Over the past few weeks, I’ve had dozens of conversations with CEOs whose products connect to Salesforce, especially AI-native and agentic companies whose workflows depend heavily on OAuth. They’re all asking the same question:

“What should we be doing right now to strengthen our integration security?”

We recently went through a security advisory involving our Connected App on Salesforce. It reinforced for us how essential strong OAuth token hygiene is when you build on a connected ecosystem. We learned a lot about attack patterns, token abuse, and how quickly expectations are shifting for anyone building on the AppExchange.

🔑 OAuth Is Your Hotel Keycard 🏨

OAuth works a lot like a hotel keycard. Instead of giving one app your master key (your actual password) it gets a keycard programmed only for the specific “room” or data it needs, and only for the length of its stay. AI and agentic systems rely on these short-lived keycards constantly as they move between tools to complete tasks. When those keycards aren’t tightly managed, the risk grows quickly.

I want to share these learnings with an eye toward helping other teams move faster. I’ve always believed in the AppExchange model, especially as someone who worked at Salesforce during the early days of its creation. As CEO of Gainsight, that belief continues.

The AppExchange works because it’s a community. When one of us strengthens our security posture, everyone benefits. So if sharing these observations helps even one CEO tighten an integration or ask a sharper question of their engineering team, that’s a win for the entire ecosystem.

Why This Matters

We’ll share a comprehensive retrospective on the Salesforce security advisory involving our Connected App in a separate Substack article. For now, I want to stay focused on a question I’ve been hearing from other SaaS CEOs: what should we be doing right now to strengthen our Salesforce Connected App?

It’s a timely question. Salesforce continues to evolve the security controls available to Connected Apps. One of the newest capabilities, Refresh Token Time-To-Live (TTL) shortens how long tokens remain valid and gives Independent Software Vendors (ISVs) more control over how their Connected Apps manage authentication. It’s an important step forward and part of a broader shift toward stronger token security across the entire ecosystem.

What Every SaaS CEO Should Know

If you’re running a product on the AppExchange, there’s a reality worth acknowledging openly: old credentials have a long half-life, and unfortunately, some end up in places they shouldn’t.

Attackers collect them, trade them, experiment with them, and every so often, they get lucky. This is true of any OAuth ecosystem and is not unique to Salesforce, which has been steadily adding safeguards to help address these risks.

We don’t have logs that go far back enough to definitively establish how every token was accessed, but based on the tokens identified, we’ve proceeded with the working assumption that they originated with our application and then focused on preventing any reuse or exploitation.

But the essential point is this: even if old credentials exist in the wild, Salesforce provides strong ways to safeguard your Connected App, ensuring those credentials can’t be used against you.

You don’t control whether old tokens exist. You control whether they’re still useful.

And Salesforce has steadily expanded the tools that make those old tokens effectively worthless. Based on what we’ve learned (and what Salesforce now enables), here are the four areas every AppExchange team should prioritize.

---

1. Use Shorter Refresh Token Lifespans

One of the most effective ways to reduce token risk is to limit how long refresh tokens remain valid. In collaboration with Salesforce, we’re enforcing a shorter Time To Live (TTL) for refresh tokens used by our Connected App. This limits how long a token can be used before it automatically expires and strengthens our joint security posture.

ISVs should work with their customers to limit the TTL of their refresh tokens using existing Salesforce admin controls, and to make this an ongoing conversation as OAuth security expectations continue to evolve. Salesforce already provides admin-level controls to manage how long refresh tokens remain valid — including policies like “expire refresh token after” — which we encourage teams to review thoughtfully (see point 7 in this Salesforce help article).

Shorter TTL reduces the window in which a stolen credential could ever be misused. Even if a refresh token ends up in the hands of a bad actor, it expires quickly and loses its value. This reflects where modern platforms are heading: assuming credentials may circulate, and designing systems so they can’t be used.

Shorter TTL for refresh tokens gives CEOs confidence that:

• Tokens can’t linger indefinitely

• Any compromised token ages out quickly

• The integration behaves like a rotating lock, not a static one

🔑 Tokens Need a Checkout Time ⏰

Think of TTL (‘time to live’) as the hotel automatically resetting every keycard at checkout. Even if someone finds an old keycard later, it won’t open anything because it’s already expired. Shorter TTL simply means the “checkout time” comes sooner — so even if a token ends up in the wrong hands, it stops working before it can cause trouble.

---

2. Enable Refresh Token Rotation

Refresh Token Rotation (RTR) ensures that each refresh token can only be used once. Every time an access token is requested, Salesforce issues a new refresh token and immediately invalidates the previous one. That means even if an old refresh token ends up in the hands of a threat actor, it can’t be reused.

RTR matters even more for distributed and AI-native systems, where multiple workers or agents may operate in parallel and token misuse can create ripple effects. By rotating refresh tokens automatically, you limit the value of any token that’s intercepted or accidentally exposed.

RTR gives CEOs confidence that:

• Token reuse will fail silently and safely

• Attackers can’t “replay” old credentials

• Your architecture stays resilient even if individual tokens leak

🔑 Your Key-Issuing Code Should Always Change ♻️

Your refresh token is like a secret code you share with the hotel front desk so they can issue you a new room key without asking for your ID each time. If someone steals that code, they could try to get the front desk to make keycards for them. RTR protects you by rotating that code every time it’s used and disabling the old one, so any stolen code is useless.

---

3. Implement OAuth PKCE

Proof Key for Code Exchange (PKCE) adds a critical safeguard to OAuth flows. It requires the app that starts the authentication process to prove it’s the same app that finishes it. This works through a one-time cryptographic value (a “verifier”) that only the legitimate app can provide during the token exchange. If the app can’t prove its identity with that verifier, Salesforce simply won’t issue access or refresh tokens.

For modern Connected Apps, PKCE is the expected baseline. It closes an entire category of interception attacks with relatively little implementation effort and keeps your authentication flows aligned with the standards used across major platforms and mobile clients.

PKCE gives CEOs confidence that:

• OAuth flows can’t be hijacked

• Intercepted authorization codes can’t be turned into tokens

• The Connected App follows modern, secure OAuth practices

🔑 Only the Right Guest Can Use the Key 🧬

In our hotel keycard example, PKCE is the front desk verifying you’re the same guest who checked in before any door opens. Even if someone copied the number on your keycard, they couldn’t use it. Only you have the one-time proof the system expects. Intercepting the “code” gets an attacker nothing but a closed door.

---

4. Enforce Trusted IP Ranges

Limiting where token exchanges can originate is one of the simplest and most effective defenses you can put in place. With Salesforce’s Trusted IP Range for the OAuth Web Server Flow, login and token refresh requests are only allowed from infrastructure you trust. In practical terms, this means Salesforce will only hand out new access tokens when the request comes from your own servers — not from random machines on the internet, even if someone has a previously valid credential.

It’s a straightforward application of the principle of least privilege. A token is only as powerful as the environment allowed to use it. Enforcing Trusted IP Ranges prevents stolen credentials from being weaponized on unfamiliar networks and keeps authentication traffic inside known, controlled boundaries. And while this greatly strengthens your Connected App, it’s designed to complement (not replace) Salesforce’s org-level and profile-level IP restrictions.

Trusted IP restrictions give CEOs confidence that:

• Stolen tokens can’t be weaponized from unrecognized networks

• Authentication traffic stays inside known boundaries

• Your OAuth surface becomes narrower, simpler, and safer to manage

🔑 Keycards Only Work at the Door 🚪

Trusted IP Ranges work a lot like mobile hotel keycards. Even though you can technically “try” to unlock the door from anywhere, it’ll only open if you’re standing right in front of it. If someone clones your digital key and tries it from a different location, nothing happens. IP Ranges work the same way for your Connected App: token exchanges only succeed when they come from locations you trust, and nowhere else.

---

What We Took Away

CEOs don’t need to be deep in OAuth internals to be proactive. But you do need to ask your teams the right questions. Given what Salesforce now enables (and what we’ve implemented) these four questions belong on every CEO’s checklist:

1. Are we using token rotation everywhere it applies?

2. Have we implemented PKCE across all authentication flows?

3. Are we ready for shorter token lifespans and the operational habits they require?

4. Are token exchanges restricted to trusted network locations?

Looking Ahead

Our applications are fully reconnected to Salesforce. We’ve implemented the latest security enhancements available to us and will continue to keep pace with Salesforce as the platform evolves.

Every ISV must grapple with the reality that old credentials can circulate in places we don’t control, and attackers will occasionally test them. That’s the nature of OAuth ecosystems. What matters is that Salesforce now provides ways to neutralize those credentials, even if someone gets their hands on them. Controls like shorter token lifespans, token rotation, PKCE, and trusted IP ranges make those old tokens effectively useless.

Most importantly, we want a strong ecosystem. If what we learned helps another company spark an important internal conversation, then some good will come from a challenging experience. That’s how platforms and communities stay and grow more resilient.

— Chuck Ganapathi

💭 Connect with me on LinkedIn

If you have immediate questions, reach out to support@gainsight.com.