Secure Your Connected Apps and External Client Apps

Proof Key for Code Exchange

PKCE (Proof Key for Code Exchange) protects the OAuth authorization code flow against interception attacks on authorization code, especially for public clients, like mobile apps. Partners must enable PKCE in the OAuth settings of their Salesforce Connected Apps and ECAs, regardless of whether the client is public or confidential.

For Public Clients, the token exchange request must not include the client_secret parameter. The presence of the correct code_verifier parameter is the only mechanism for verifying the client's identity.

For Confidential Clients, the token exchange request must include both the code_verifier parameter, for code binding, and the client_secret parameter, for client authentication, in the /services/oauth2/token endpoint request.

Partners must also make sure that they implement the client changes referenced below. After PKCE is enabled, the Partner Application’s Connected Apps and ECAs won't work unless the client changes listed below are implemented.

Client changes:

• Generate code_verifier parameter: Create a high-entropy, random string (43-128 chars).
• Create code_challenge parameter: Hash the code_verifier, using SHA256 and BASE64URL to encode it.
• Authorization request: Include code_challenge and code_challenge_method=S256 parameters in the request to the authorization server.
• Token request: Send the original code_verifier parameter, not the hash, when exchanging the authorization code for an access token.

For more information, see Enabling PKCE for OAuth for Salesforce External Client and Connected Apps and Proof Key for Code Exchange (PKCE) Extension.

Refresh Token Rotation

Refresh Token Rotation (RTR) enhances security by invalidating the old refresh token, and replacing it with a new refresh token, after a new access token is issued. Stolen tokens are invalidated upon the next refresh token flow, which limits the window of opportunity for an attacker if a refresh token is compromised. It's a critical defense against long-term session hijacking.

Partners must have RTR enabled in the OAuth settings of all of their Salesforce Connected Apps and ECAs.

Partners must also make sure that they implement the client changes referenced below. After RTR is enabled, the Partner Application’s Connected Apps and ECAs won't work unless the client changes listed below are implemented.

Client changes:

• Implement code changes to capture the new refresh token returned by the refresh token flow and store the new refresh token securely.
• Implement robust error handling to detect when a refresh token is rejected. Sometimes a failed refresh token flow indicates that the token was compromised.
• Applications that make parallel refresh token flow requests may encounter potential race conditions where multiple requests try to use the same, about-to-be-invalidated refresh token. Your client implementation should handle potential race conditions.

For more information, see Force one-time-use Refresh Tokens - (RTR) Refresh Token Rotation and OAuth 2.0 Refresh Token Flow for Renewed Sessions.

Deadlines for Implementation

All Partners must implement the preceding requirements for Connected Apps and ECAs by the deadlines set forth below.

Report Suspicious Activity

Any suspicious activity or security incidents that impact a Partner’s applications or solutions and/or the customer integrations with a Partner’s applications or solutions must be reported by the Partner immediately to the Salesforce security team by emailing security@salesforce.com for further investigation.