Starting in July 2026, Salesforce enforces OAuth security controls for new external client apps and connected apps. The Proof Key for Code Exchange (PKCE) extension is required for apps that use the authorization code grant type. For apps that use the refresh token flow, Salesforce requires two controls: refresh token rotation and a 30-day limit to the time-to-live (TTL) for idle refresh tokens.
Where: This change applies to Lightning Experience and Salesforce Classic in all editions.
When: This change applies to external client apps and connected apps that are created in July 2026 and later. With the exception of Partner Applications, these controls aren't currently enforced for apps that were created before July 2026. However, to protect your data, we strongly recommend that you implement these controls across all of your apps.
When Salesforce first released this change in July 2026, the setting to require PKCE was auto-enabled and locked only for new apps where the callback URL was set to a localhost or custom scheme URL. Starting in August 2026, this setting is now auto-enabled for all new apps, regardless of the callback URL.
For connected apps that were created before July 2026, if you migrate to an external client app, Salesforce doesn't enforce these controls for the migrated app. Also, if a subscriber installs an app that was created before July 2026, Salesforce doesn't enforce these controls for the installed instance of the app. The enforcement is based on when the app was created in the source org.
Why: These controls protect your Salesforce data from unauthorized access. PKCE prevents interception attacks, where attackers steal an authorization code and exchange it for an access token. Refresh token rotation and the idle TTL limit make it harder for attackers to use compromised refresh tokens to get new access tokens.
How: Salesforce enforces these controls by auto-enabling and locking OAuth settings for new external client apps and connected apps. This includes apps that you create via the UI, metadata, or dynamic client registration. Use this table to understand the requirements and enforcement behavior for each flow.
| Security Control | Applicable OAuth Flows | UI Behavior | Client-Side Code Requirements |
|---|---|---|---|
| PKCE: ensures that the client who initiated the flow is the same client who completes the flow. |
PKCE is enforced for these OAuth flows.
|
When you save a new app, Salesforce auto-enables the Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows setting, locks it, and grays it out. |
The client must implement PKCE for applicable OAuth flows:
|
| Refresh token rotation: each time a refresh token is used, Salesforce invalidates it and issues a new one. | When you create an app, the Enable Refresh Token Rotation setting is auto-enabled, locked, and grayed out. | The client-side code must be able to handle the new refresh token and store it securely. | |
| Idle refresh token TTL: limits the validity period for unused refresh tokens to 30 days. Each time a token is used within the 30 day-period, the idle TTL resets. | When you create an app, the Limit Idle Refresh Token Time-to-Live (TTL) to 30 Days setting is auto-enabled, locked, and grayed out. | This control doesn't require any changes on the client side. Optionally, to avoid re-authorizing, you can update your code to initiate a refresh token flow before the 30-day limit and receive a new refresh token. |