Salesforce OAuth security controls: what new integrations need from July 2026

Creating an OAuth app in Salesforce can look like a short configuration task: select a flow, add a callback URL, choose scopes and issue credentials. From July 2026, stronger controls for newly created external client apps and connected apps make the client application's behaviour just as important as the setup record.

Salesforce's Summer '26 release notes confirm that new apps are subject to enforced controls for Proof Key for Code Exchange (PKCE) and refresh-token handling. These changes are sensible security improvements, but they can expose assumptions in mobile apps, desktop tools, browser-based utilities and custom integrations. The practical task is to make sure the Salesforce configuration, client code and operating model agree before production use.

What Salesforce has confirmed

Salesforce says that, starting in July 2026, it enforces OAuth security controls for new external client apps and connected apps. For apps using the authorisation-code grant type with a localhost or custom-scheme callback URL, PKCE is required. For apps using refresh tokens, Salesforce requires refresh-token rotation and a 30-day idle time-to-live.

This article deliberately describes the published scope as new apps. It should not be read as a claim that every existing connected app changes on the same date. Existing estates still deserve review, particularly where controls can be enabled and locked, but teams should confirm behaviour against the app's own configuration and current Salesforce guidance rather than apply a blanket assumption.

Salesforce's separate post-enforcement partner guidance discusses four controls: PKCE, refresh-token rotation, a 30-day idle limit and refresh-token IP allowlisting. That guidance is aimed at partner applications affected by technical enforcement. The release note for new apps is narrower in how it states the mandatory controls, so app owners should check which controls apply to their app type and channel.

Why PKCE changes the client, not only the setting

PKCE adds a per-authorisation proof to the OAuth authorisation-code flow. The client creates a secret value known as a code verifier and sends a derived challenge when authorisation starts. It must later present the matching verifier when exchanging the authorisation code for tokens.

The security benefit is that an intercepted authorisation code is less useful without the verifier. Operationally, however, enabling a checkbox does not add PKCE support to an old client. The application must generate the values correctly, preserve the verifier for the short authorisation journey and send it during the token exchange.

Localhost callbacks are common in developer tools and local utilities. Custom URI schemes are common in native mobile and desktop applications. Those are precisely the situations where teams should identify the application version that introduced PKCE support and test the complete sign-in journey. A successful redirect is not enough; the code exchange and subsequent API call must also succeed.

Refresh-token rotation needs careful state management

Refresh tokens allow an application to obtain new access tokens without asking the user to sign in every time. With rotation, a successful refresh returns a replacement refresh token and invalidates the previous one. The client must securely store the new value before it is needed again.

This can reveal a race condition. If two workers try to refresh the same session at nearly the same time, one may replace the token while the other still attempts to use the old value. Salesforce's partner guidance explicitly tells developers to capture each new token and handle potential race conditions.

The 30-day idle time-to-live is a sliding window: Salesforce's release notes say it resets when the token is used within that period. This is not the same as saying a token can never last longer than 30 days. It means an inactive integration can lose its refresh path and require the user or administrator to authorise it again. That distinction matters for seasonal processes, rarely used utilities and disaster-recovery tooling.

Who needs to be involved?

Salesforce administrators usually own app registration, scopes, permitted-user policy and assignment. They need enough information from developers to recognise the actual OAuth flow and callback behaviour.

Integration developers or vendors own PKCE generation, token replacement, secure storage, concurrency and error handling. If a vendor product creates the app, ask for the supported version and written confirmation of its Salesforce OAuth behaviour.

Security and identity teams should review whether scopes, user assignment, IP restrictions and credential storage match organisational policy. They also need a workable re-authorisation and revocation process.

Platform owners and operations teams should insist on named ownership, monitoring and support documentation. A secure configuration is not operationally complete if nobody knows who responds when an idle token expires.

A practical readiness checklist

1. Classify the integration. Record whether it is an external client app or connected app, who created it, which environment it serves and whether a vendor or internal team owns the client code.
2. Write down the OAuth flow. Do not rely on the label “OAuth”. Confirm the grant type, callback URI pattern, scopes, permitted-user policy and whether refresh tokens are issued.
3. Verify PKCE support where required. Confirm the client generates a fresh verifier and challenge for each authorisation attempt and completes the token exchange successfully.
4. Test rotation under concurrency. Check that the application persists the replacement refresh token safely. Simulate overlapping refresh attempts and confirm failures do not leave the integration permanently disconnected.
5. Plan for 30 days of inactivity. Identify integrations that may be dormant for a month. Document the expected error, the person authorised to reconnect the app and the user impact while it is unavailable.
6. Review token storage and logs. Tokens should not appear in ordinary application logs, support screenshots or tickets. Confirm encryption, access control and redaction with the system owner.
7. Test away from production. Salesforce's partner guidance recommends validating changes with a parallel external client app in a sandbox or scratch org because enforced controls on a production app cannot simply be toggled for testing.
8. Monitor the first production cycles. Observe authorisation, refresh, expiry and revocation events. Agree an escalation route across Salesforce, application and security owners.

Questions to ask a software vendor

For a third-party product, ask which version supports Salesforce's enforced OAuth controls, whether an upgrade or re-authorisation is required, how the product serialises refresh attempts, and what administrators will see when a token becomes idle. Ask for an implementation date rather than a general statement that the product “supports OAuth”.

If the answer depends on IP allowlisting, also ask whether the vendor has stable, publicly routable egress addresses and how changes are communicated. Do not enable a restrictive allowlist on an assumption: cloud services may use larger or changing ranges.

The Ostrelis view

The confirmed Salesforce change is a security baseline for newly created apps. The broader operational lesson is an Ostrelis interpretation: OAuth configuration and client implementation must be reviewed together. Admins should not be expected to infer code behaviour from Setup, and developers should not assume that a token endpoint will preserve older client behaviour indefinitely.

A lightweight integration record can close that gap. For every important connection, keep the owner, business purpose, app type, OAuth flow, scopes, callback URLs, token behaviour, test evidence, monitoring and recovery route in one place. That record is useful for this July 2026 change and for later security updates, vendor upgrades and staff transitions.

Ostrelis can help organisations map Salesforce integrations, review authentication dependencies and turn technical changes into controlled operational work. See our Salesforce data and integration services, Salesforce health check and managed Salesforce services.