Summary A 2GP managed-package External Client App (ECA) installs successfully in a subscriber org, but the OAuth 2.0 web-server flow from that subscriber org fails at authorization with: error=OAUTH_AUTHORIZATION_BLOCKED error_description=Cross-org OAuth flows are not supported for this external client app We are migrating from a Connected App (which worked cross-org) to a packaged ECA due to the Connected App deprecation. We need to know what configuration allows subscriber orgs to complete OAuth authorization against our packaged ECA. Environment - Packaging / Dev Hub org: jeff.qiu.c0c4028cfddb@agentforce.com — Org Id 00Dg500000CfSJBEA3 - Managed package (2GP): coachpilot-sf-eca, package Id 0Hog50000000piTCAQ, namespace cpsftest - Package version: 04tg50000009p05AAA (0.1.0.1) — Released = true - External Client App CoachPilotSF: distributionState=Packaged, Status Enabled, scopes Api, RefreshToken, callback https://staging-api.coachpilot.com/api/v1/crm/salesforce/callback, PKCE (S256), oauthLink → 00Dg500000CfSJB:888g5000000Z6k5 - Consumer key (unchanged after packaging): 3MVG9QJ.PEcC... - Model: external SaaS backend runs the OAuth web-server flow using the single Dev Hub consumer key across all subscriber orgs. Steps to reproduce 1. Subscriber installs released package 04tg50000009p05AAA — succeeds (ECA present, DistributionState=Packaged). 2. Subscriber ECA policy set to "All users may self-authorize". 3. OAuth web-server authorize from the subscriber's own My Domain: https://.my.salesforce.com/services/oauth2/authorize?response_type=code&client_id=<Dev Hub consumer key>&redirect_uri=<callback>&scope=api%20refresh_token&code_challenge=<...>&code_challenge_method=S256 4. Result: redirected with OAUTH_AUTHORIZATION_BLOCKED — Cross-org OAuth flows are not supported. Already confirmed (no need to re-check) - Package version Released (not beta); subscriber install succeeds; ECA DistributionState=Packaged. - Subscriber policy = "All users may self-authorize". - Consumer key = Dev Hub ECA's, unchanged. - Authorize attempted from the subscriber's own My Domain AND from login.salesforce.com — both blocked; the flow reaches the consent page, block is at grant. Cannot inspect (suspected cause) - The Dev Hub ExtlClntAppGlobalOauthSettings (global OAuth settings) — not retrievable via Metadata API source, describe empty via Tooling API, not editable in UI. Suspect a required cross-org/distribution "trust" setting on the global OAuth settings. Questions 1. For a packaged ECA (2GP), what config on the packaging org's global OAuth settings (ExtlClntAppGlobalOauthSettings) lets subscriber orgs complete the web-server OAuth flow using the packaging org's consumer key? 2. Is Cross-org OAuth flows are not supported expected when a subscriber (with the package installed) authorizes using the packaging org's consumer key? What is the supported ISV pattern? 3. Must each subscriber generate their own global OAuth settings (per-subscriber consumer key)? If so, how does the external backend obtain each org's consumer key programmatically? 4. Any limitation with the packaging org being an @agentforce.com (trial/dev) org type for cross-org ECA OAuth distribution? Desired outcome Customer installs the managed package, authorizes via OAuth web-server flow, and our backend receives that org's access/refresh tokens — the Connected App experience, via ECA.
Hi Jeff!
Your setup looks close to the supported packaged-ECA model. Salesforce documents that a packaged External Client App can either generate its own OAuth global settings in the subscriber org or reference the global OAuth settings from the source/packaging org. In the latter model, the subscriber ECA’s OAuth link should reference the source org and its consumer ID.
So I wouldn’t expect the subscriber to automatically need a separate consumer key just because the package is installed. Salesforce specifically documents the source-org global-settings association for OAuth.
One thing I’d verify is the actual ExtlClntAppOauthSettings OAuth link in the installed subscriber app and confirm it points to the source org/global OAuth settings exactly as documented. If the subscriber instead has its own global settings, then it will have its own OAuth consumer credentials.
Also, the source org needs to remain available because subscriber ECAs that reference its global OAuth settings depend on that source configuration.
Given that your OAuth request is reaching the consent page and then specifically fails with OAUTH_AUTHORIZATION_BLOCKED, I’d focus on the ECA association/global OAuth configuration rather than the subscriber policy alone.
If you can share the ExtlClntAppOauthSettings OAuth link value from the packaged ECA/subscriber, that would be the next thing I’d check.
