When does it make sense to add a Connected App to a Managed Package?

Question

I think I'm familiar with the difference between a connected app definition and its consumption:

As the vendor, my Connected App definition lives by himself in a dev org forever:

For the users, in other orgs they can see (or revoke) any Allowed apps from their user record:

The Connected App does not need to be in the package for users to 'Allow' access to it.

But Salesforce also make it possible, in a release org that has a namespace prefix and a managed package, to add a Connected App definition to a Managed Package:

Packaging a Connected App

After creating a connected app or a new version of an existing app, package it to make it available to users on other Salesforce organizations. You can add a connected app to a managed package in the same way as, and along with, other components such as custom objects, Visualforce pages, or Apex classes. This makes it easy to distribute a connected app to other Salesforce organizations. As a packageable component, connected apps can also take advantage of all other features of managed packages, such as listing on the AppExchange, push upgrades, post-install Apex scripts, license management, and enhanced subscriber support.

help.salesforce.com/apex/HTViewHelpDoc?id=connected_app_edit.htm&language=en_US

What is the use case for this, as opposed to the definition existing only in the release organization?

Answer 1

Packaging the connected app allows administrators who install the app to control which of their users can use the application.

Rather than the coarse ability to block or not block an app (seen in Setup -> Manage Apps -> Connected Apps Oauth Usage), you get the ability to control the security settings for the app in a more finely grained manner (seen in Setup -> Manage Apps -> Connected Apps -> Select App). By default Salesforce have installed packages for apps such as Chatter Desktop and Salesforce1 in all orgs.

For example:

• you can select profiles or permission sets which can use the app
• choose if IP policies are enforced (or ignore if 2FA has been used)
• choose PIN policies for a mobile app

If the Connected App is not packaged by its provider, then administrators will only have the binary option of blocking or allowing the app.

A good article on managing these permissiong can be seen here: Managing External Apps with Connected Apps | Cloud Sherpas

Answer 2

Let's say that you have a salesforce application that communicates with an API you've developed. That API connects to salesforce using the Consumer Secret and Consumer Key of your connected app, and it is used to grant access to the org using OAuth.

Now you package that app and start distributing it through the appexchange. Every time somebody installs your app, the connected app is deployed preserving the same Consumer Secret and Consumer Key, and will be able to communicate with your API.

Each OAuth grant is based on users and orgs; so the fact you granted access to that connected app on a costumer org does not grant you access to other costumer orgs also obviously.

Answer 3

For me,

The connected app allows my managed package to connect to the users org via oAuth using the single credentials defined in the connected app that is packaged. This access was required for specific purposes that could not be achieved via Apex but had to be done via tooling or metadata API.

The user still has to grant Access via the oAuth flow but we do not need to use the username / password flow.

Not sure how much this helps or not but that was my use case.

Each connected APP gets its OWN key and secret.

Another answer to the question maybe:

Connected App in Managed Package