4 New OAuth Security Requirements for Salesforce Connected Apps and External Client Apps

Starting June 25, 2026, Salesforce will enforce four mandatory OAuth security controls on every Connected App and External Client App published by AppExchange ISVs. Partners that are not compliant by that date risk suspension of their access to Salesforce APIs.

What's changing — and why now

Every major Salesforce-related breach in recent memory — Gainsight, Salesloft Drift, the ShinyHunters campaign — shared the same entry point: a compromised OAuth connection. Stolen authorization codes, dormant refresh tokens, and tokens exfiltrated to attacker-controlled infrastructure. The attackers didn't break Salesforce. They walked in through the integrations.

Salesforce's response is to mandate four OAuth controls that map directly to the techniques used in those breaches. These aren't recommendations. They're conditions for continued participation in the AppExchange ecosystem, and they apply to every Connected App and External Client App that ISVs create in their infrastructure orgs — Partner Business Orgs, packaging orgs, namespace orgs, and any developer org used to mint credentials that customers consume.

Connected Apps that customers create in their own orgs are not in scope. If subscribers authenticate to your service using credentials your team owns, these controls apply.

The four requirements

1) PKCE (Proof Key for Code Exchange)

Applies to: Authorization code flows only. Not applicable to JWT Bearer or Client Credentials flows.

PKCE closes the authorization code interception vulnerability. In a standard authorization code flow, the code is returned to the client via a redirect URI. If an attacker intercepts that redirect — through a malicious app, a compromised browser extension, or a man-in-the-middle position — they can exchange the code for an access token.

PKCE binds the authorization request to the token exchange. The client generates a random code_verifier, derives a code_challenge from it using SHA-256, and includes the challenge in the authorization request. At token exchange, the client sends the original verifier. The authorization server verifies the match. An attacker who intercepts the code can't complete the exchange without the verifier, which never left the client.

What ISVs need to do:

Generate a cryptographically random code_verifier (43–128 characters from the unreserved character set)
Compute the code_challenge as BASE64URL(SHA256(code_verifier))
Include code_challenge and code_challenge_method=S256 in the authorization request
Include the code_verifier in the token exchange request
Enable the PKCE setting on the Connected App or ECA in your source org

For packaged Connected Apps, the PKCE setting propagates to subscriber orgs automatically via the managed package.

2) Refresh Token Rotation (RTR)

Applies to: Any flow that issues refresh tokens. Not applicable to JWT Bearer flows (which don't issue refresh tokens).

RTR ensures that every time a refresh token is used to obtain a new access token, the old refresh token is invalidated and a new one is issued. A stolen refresh token is only usable once. If the legitimate application uses it first, the stolen copy is dead.

This is the most implementation-intensive of the four controls. RTR introduces a failure mode that can break production if handled incorrectly. If a client attempts to redeem an already-rotated token — because of a retry, a race condition, or a bug — Salesforce treats this as a stolen-token event and invalidates all refresh tokens for that user-application pair. One buggy retry can drop the entire session.

What ISVs need to do:

Transactional token storage: When you receive a new refresh token, persist it atomically before making any subsequent API calls. If your app crashes between receiving a new token and storing it, the old token is already dead.
Single-writer-per-chain: In multi-worker architectures, only one process should redeem and store refresh tokens for a given user-app pair. Concurrent redemptions will trigger the stolen-token cascade.
Retry logic: Never retry a token exchange with the same refresh token. If the exchange fails ambiguously, assume the token has been rotated and re-authenticate the user.
Error handling: Detect Salesforce's stolen-token invalidation response and trigger a clean re-authentication flow rather than looping on the invalid token.

RTR is not a toggle-and-forget setting. Enable it only after your token handling logic has been updated and tested.

3) 30-Day Idle Timeout

Applies to: Any flow that uses refresh tokens.

Refresh tokens that aren't used within 30 days expire automatically. This kills the dormant-token attack vector — where a long-lived refresh token sits unused in a compromised system until the attacker is ready to exploit it.

For integrations that run continuously — daily syncs, real-time webhooks — this is invisible. The tokens refresh regularly and never go idle.

For integrations that run infrequently — quarterly reports, seasonal campaigns, apps users open sporadically — this requires a heartbeat mechanism: a scheduled job that refreshes the token every 25–28 days to keep it alive without waiting for user-initiated activity.

Mobile apps face a particular challenge. If a user installs the app but doesn't open it for 30 days, the token expires and they'll need to re-authenticate. There's no effective server-side heartbeat for client-held tokens. ISVs with mobile apps should plan for a re-authentication UX that handles this gracefully — not as an error state, but as a normal flow.

4) IP Range Allowlisting

Applies to: Any flow that uses refresh tokens.

Refresh tokens can only be redeemed from IP addresses registered in the Connected App or ECA's allowlist. A stolen refresh token exfiltrated to attacker infrastructure is useless if it can't be redeemed from the attacker's IP range.

This is the most operationally demanding control for ISVs whose infrastructure doesn't use static egress IPs. Cloud-native architectures often use dynamic IP ranges, and establishing static egress requires infrastructure-level changes.

What ISVs need to do:

Configure a static egress gateway (NAT gateway, proxy, or similar) for all outbound Salesforce API traffic
Register those static IPs with Salesforce via a support case
Wait for confirmation and validation
Cut over application traffic to route through the static egress
Remove old dynamic ranges

For ISVs already using static IPs for Salesforce communication, this is a configuration change. For those on dynamic infrastructure, it's a multi-step infrastructure project that needs to be scoped and executed well before June 25.

Which controls apply to which flows

Not every control applies to every OAuth flow. This matrix maps requirements to flow types:

Control	Authorization Code	JWT Bearer	Client Credentials
PKCE	Required	Not applicable	Not applicable
Refresh Token Rotation	Required (if refresh tokens issued)	Not applicable (no refresh tokens)	Not applicable (no refresh tokens)
30-Day Idle Timeout	Required (if refresh tokens issued)	Not applicable	Not applicable
IP Allowlisting	Required (if refresh tokens issued)	Required	Required

For ISVs running JWT Bearer flows exclusively — common for server-to-server integrations — the compliance path is straightforward: configure the IP allowlist, document the exemptions for inapplicable controls, and validate in sandbox. No client code changes are required.

For ISVs running authorization code flows with refresh tokens, all four controls apply and the work is more involved.

Migration paths

ISVs have three options for achieving compliance. Different apps in a portfolio can take different paths.

Path A: Hotfix the existing Connected App. Enable PKCE, RTR, idle timeout, and IP allowlisting on the existing Connected App in the source/packaging org. These settings propagate automatically to subscriber orgs via the managed package. No new Consumer Key, no customer re-authentication, no Security Review resubmission for the settings change alone. Application-side code changes (PKCE handshake, RTR token handling) are still required. This is the fastest path to compliance.

Path B: Full ECA migration. Create a new External Client App, package it into a 2GP managed package, update application code to use the new Consumer Key, resubmit the AppExchange Security Review, and coordinate customer re-authentication. This is the strategic long-term path — Connected App creation is already disabled as of Spring '26 — but it's a larger project than the June 25 deadline demands.

Path C: Sidecar 2GP. Create a separate 2GP package containing only the ECA metadata, distributed alongside your existing 1GP package. This decouples the ECA migration from a full 1GP-to-2GP migration and avoids forcing customers to switch Consumer Keys immediately.

Path A buys time. The full ECA migration is still on the roadmap for every ISV — Salesforce has blocked new Connected App creation and will eventually stop granting exceptions entirely.

What happens if you don't comply

This is not an advisory with soft deadlines. Salesforce has stated that non-compliance can result in:

AppExchange de-listing of the non-compliant app
Temporary suspension of the app's access to Salesforce APIs
Permanent suspension if issues are not remediated

Starting June 25, 2026, Salesforce will begin enforcement. Partners that have not implemented the required controls by that date risk having their apps suspended — meaning their customers lose access to the integration. The blast radius of non-compliance extends to your entire customer base.

Compliance checklist

How Security Review Partner helps

Our analysis engine parses your Salesforce Code Analyzer and Checkmarx scan results and flags OAuth-related vulnerabilities — including missing PKCE implementation, insecure token storage patterns, and hardcoded credentials that would fail these new requirements. If you're preparing for the June 25 deadline or an AppExchange Security Review submission, upload your scan results and get AI-powered remediation guidance specific to your codebase.

Additional resources

The controls Salesforce is mandating are not arbitrary. Each one maps to a technique that was used in a real breach against a real ISV's customers. The June 25 deadline is the compliance floor. The work to get there — especially RTR token handling and static egress infrastructure — should be underway now.