Creating Auth Providers and Named Credentials for an installed Managed Package is not a simple process. Most Subscriber Admins are overwhelmed by the settings. For that reason, many AppExchange packages automated the creation of those artifacts using APIs.

Recently the Security Review rules were changed, and such automation is not possible anymore. I am now thinking about how to simplify the process for the Subscriber Admin. The main idea is to package partially configured Named Creds and Auth Providers in the Managed Package and have the Admin only complete them with a Client Id and Secret.

  1. Admin installs the app from Appexchange. It contains a preconfigured Named Credential and Auth Provider.
  2. Admin registers Salesforce Org on External Service and receives Client Id/Secret
  3. Admin adds Client Id and Secret to Named Cred and Auth Provider.
  4. Admin authorized using OAuth flow.
  5. Our app can connect to the API using the Named Credential

I also know that there is a new type of Named Credentials available.

NOTE: I know this overlaps with Is it posibble to edit Named Credential url in a managed package?, but this answer does not cover the OAuth part from AuthProvider.

1 Answer 1


Yes, it is possible to do it, both with the Legacy and NextGen Named Credentials.

What would be packaged

  1. Named Credential
  2. External Credential (in case of a NextGen)
  3. An Authentication Provider, as oAuth is used in the mentioned scenario. In case of OpenId type, it should be packaged with dummy values for consumer key and secret, because those are required for that provider type. Note that in the case of a Legacy Named Credentials, it will point to this Authentication Provider, and in the case of NextGen, the External Credential will do the link.

What would be manually modified by an Admin after package installation

  1. The Authentication Provider's customer secret and key.
  2. Optionally, in the NextGen Named Credentials, authentication headers can be added by an Admin by creating a permission set mapping, as well as custom headers, all of those in the packaged External Credential.

Note 1: For scenarios where a basic auth is to be used, i.e an API Token, I would rather use a Protected Custom Setting together with a remote site setting for simplicity.

Note 2: This would not be possible to be automated using the Metadata API, as the Authentication Provider consumer secret update is not allowed through the API. Hence it would work for creating a new Authentication Provider with the API but not updating a partially packaged one.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .