Connected Apps (CAs) and External Client Apps (ECAs) AppExchange Security Review Submission Guidance

Connected App & ECA

Connected Apps (CAs) and External Client Apps (ECAs) enable third-party applications to integrate with Salesforce by using Salesforce APIs and standard security protocols, such as SAML, OAuth, and OpenID Connect. CAs and ECAs use these security protocols to authenticate, authorize, and provide single sign-on (SSO) for third-party applications. 

Security Review Scope and submission guidance

The security review of managed packages encompasses a thorough examination of several areas. This includes the configuration of the packaged Connected App/ECA, as well as the integrations employed by the application. All integrations of the managed package are in scope for ‌security review. This includes reviewing web applications, REST APIs, mobile apps and/or browser plugins and Desktop Apps.

Security Review Submission Guidance

Packaging

• New integrations must use ECAs instead of Connected Apps

• CAs and ECAs should be packaged for distribution on AppExchange. Below are a couple of use cases where packaging is mandatory. 

  • However, there may be use cases, where an ECA needs to be created on the subscriber org post installation. Where applicable, document the use case in the submission.

• Don't delete existing Connected Apps or ECAs from the org or remove them from the package before evaluating the impact of such actions.

  • If you have any questions about packaging, reach out to customer support.

Security Practices

• Make sure to onboard your CA/ECA to the security controls documented here.

• Apps must not rely on the following Oauth flows:

  • Device flow

  • Implicit grant flow

  • Username/Password flow: this flow is retiring in Winter’27

• CAs/ECAs should apply the principle of least privilege in using scopes.

  • If the app requires web or full scopes, a comprehensive justification must be submitted explaining why the scopes are required. For example, a real authentication protocol supplements such scope.

  • Additionally, if web scope is used, apps must not extract the session ID from the frontdoor URL.

• In general, apps should avoid using mixed-use callback URLs in a single app.

  • Use separate apps for public and confidential clients.

  • Localhost call back URL should not be combined with any other callback URL.

• Use Oauth token instead of session ID for invoking metadata API in Apex, for more details, see: 

  • Security Considerations for Session IDs

  • Sample Connected App and ECA implementations

Use of Subscriber created CAs/ECAs and packaged secrets

• Use protected custom settings to store subscriber owned secrets.

• Use Protected custom metadata to store packaged secrets.

• This requires the subscriber to rotate the secrets regularly and document how the secrets can be updated.

Securing the Secrets with third-party applications

Robust security measures must be in place to protect various secrets used in the CA/ECA use cases. This includes secure packaging of secrets, safeguarding client key, client secret and encryption keys, certifications etc. within web applications, and securely storing auth and refresh tokens. 

• Public clients must not rely on client secret for Oauth flows.

• Rotate client ID and client secret regularly.

Find more information about secure secrets management here.

Submission Documentation

• Disclose in detail the use of Connected Apps and ECAs within the solution.

• Document and explain how secrets are secured.

• For packaged ECAs, share the client key only in the submission documents, don't share the client secret.

• Credentials for integrations, including web apps and REST APIs must be submitted to avoid delays in the security review.

• If the CA/ECA is packaged independently or as an extension package, submission documentation should include the details of the base package.

• ISVs must submit detailed documentation on how the secrets are secured on their backend infrastructure.

Securing the Packaging Orgs (1GP), Namespace Definition Orgs (2GP), and DevHubs

Robust security measures are essential for the integrity of these critical organizational environments. 

• ISVs must ensure contact information is always current for critical organizational environments and that the designated contact person is responsive.

• No user within these organizations should possess the Use Any API Client permission.

• Restrict access to the orgs

  • Multi-factor authentication (MFA) must be enforced for all users.

  • IP allowlisting should be implemented to restrict access to these orgs.

• These orgs must not have untrusted Connected Apps or ECAs installed.

• These orgs must not host sites that allow guest user access.

• Don't install untrusted  packages on these orgs. 

• Rotate secrets regularly

  • User passwords, including API users, should be rotated at least once a year.

  • The client key, client secret, and certificate must be regularly rotated.

Reporting

Any suspicious activity or security incidents that impact your applications and/or the customer secrets for your applications must be reported immediately to our security team by emailing security@salesforce.com for further investigation.