Skip to main content
Topics#Appexchage AppsFrage von Aron Marinescu
Aron Marinescu fragte in #Appexchage Apps
22. Juni, 10:00

Security Review – clarification on ECA vs Connected App and packaging requirement

We are in security review for our AppExchange solution. Our app is an external SaaS that uses a single partner-owned OAuth app; subscribers authorize it via the OAuth 2.0 web-server flow (Authorization Code + PKCE), and the app is NOT installed into subscriber orgs.   

The reviewer asked us to either package an External Client App (ECA) within the managed package or justify not doing so, and to enable four controls: PKCE, Refresh Token Rotation, IP allowlist for refresh token redemption, and Refresh Token Rotation Idle Timeout.   

Could you please confirm:   

  1. For a partner-owned app that is not installed in subscriber orgs, is it acceptable to NOT package it and instead provide a justification?
  2. Can the four mandated OAuth controls be applied on our existing **Connected App**, or is migration to an **External Client App** required?

 

Thank you.   

1 Antwort
  1. Sai T (Raleigh Developer Group)
    28. Sept., 17:36

    Hi Aron!

    Based on Salesforce’s current AppExchange security-review guidance, your use case appears to fall under the packaging requirement.

    For an Authorization Code/Web Server flow where the callback URL is controlled by the ISV partner, Salesforce currently lists the integration as requiring packaging. The fact that the SaaS application itself isn’t installed in subscriber orgs doesn’t by itself remove that requirement. 

     

    Also, Salesforce is moving new integrations toward External Client Apps (ECA). Existing Connected Apps can continue to operate, but Salesforce recommends ECAs for new integrations. 

     

    So I would clarify with the reviewer whether they specifically require the existing Connected App to be migrated to an ECA, rather than assuming the four requested controls can all be enabled on the existing Connected App. Salesforce documents ECA-specific OAuth security controls such as refresh-token rotation and IP restrictions.

    For the security-review response, I’d also explicitly describe your OAuth flow, who owns the callback URL, where refresh tokens are stored, and how PKCE/refresh-token protection is implemented. That should make it easier for the reviewer to confirm the expected configuration.

Antwort schreiben...
0/9000