I have to design an external app which will retrieve information from Salesforce. Any user can install this app and use it. This app will use rest API to access information from Salesforce. I cannot force the users belonging to multiple orgs to create a connected app in their instance to generate consumer key and consumer secret. Ideally users must be able to enter username and password+security token to access the data. Is there a way to achieve this or any other way without much customization by the admin.

  • Saranya, can you add any details/specifics about how you resolved this per your comment, you were "able to implement the functionality via Username - password flow" Was this in PHP or something else? Thanks – Xtremefaith Nov 25 '14 at 19:32
  • @Xtremefaith I tried this functioanlity in apex itself. I was able to access another developer org from my developer org using username-password flow. – Saranya Jan 20 '15 at 10:40

Definitely doable. The admin should not have to customize anything:

  1. create your Connected App, once, in an org with a managed package and namespace,
  2. bake that exact client_id into the runtime code that you distribute,
  3. use Web Server authentication flow or Username-Password flow when calling REST API,

Maybe there is a misunderstanding of how Connected App really operates here. Imagine a Salesforce Package as an analogy. You control the true source code in a Packaging / Release Org but you deploy or install a special instance of it. Similarly with a Connected App:

  • you control the Connected App 'definition' including client_id and secret,
  • a user allows (or a sysadmin can manage) the connected app 'instance' when it's used.

Does this help?

  • 1
    solid answer, this is a regular misconception of OAuth clients – thegogz Nov 17 '14 at 14:23
  • 1
    The app is not a Salesforce app. This will be a mobile app which can be installed by anyone. This means that multiple org users will use it. Do you still mean that this app can just hard code client_id and secret from some sample org and access other orgs without creating the connected app in each and every org? – Saranya Nov 17 '14 at 14:42
  • 1
    Yep @Saranya you got it! The client_id and secret will be the same for everyone who uses the app. But don't use just any 'sample org', make a special org with a namespace and hold onto it. – bigassforce Nov 17 '14 at 14:49
  • 1
    Don't distribute an app containing a secret. If you do, it's not really a secret any more. As Daniel says, use the user-agent flow. – metadaddy Nov 18 '14 at 3:08
  • 1
    You just don't use the secret with user-agent flow - see developer.salesforce.com/page/… – metadaddy Nov 19 '14 at 0:27

@bigassforce's answer is correct in that you don't need separate connected apps for each org.

As per metadaddy's comments, for an external app the OAuth 2.0 User-Agent Flow is more secure with Salesforce handling the username and password input and the secret not being embedded in the application that is distributed to the client.

From the docs (my emphasis):

[For applications] implemented in a browser using a scripting language such as JavaScript, or from a mobile device or a desktop application. These consumers cannot keep the client secret confidential. The authentication of the consumer is based on the user-agent's same-origin policy.


This user-agent authentication flow doesn't utilize the client secret since the client executables reside on the end-user's computer or device, which makes the client secret accessible and exploitable.

Generally speaking, don't do the following unless someone has a gun to your head. It's much better all round for everyone if the user never directly gives you their credentials.

That said, there are alternatives available, such as the OAuth 2.0 Username-Password Flow. Once you have collected the username and password+securitytoken you can use the password grant_type to get an access token.

Also note that the access token is generally interchangeable with a session id (depending on the scope requested). You could also get the session id from the SOAP API login methods, composite apps, or even from a browsers Salesforce sid cookie.

  • 3
    Please don't collect the password from the user and use username/password flow! :-o – metadaddy Nov 18 '14 at 3:09
  • 1
    @metadaddy I've added some clarification and stronger wording about usage. It is still an option, even if it is less than ideal. :-) – Daniel Ballinger Nov 18 '14 at 6:44
  • 2
    Cool. Handling user credentials unnecessarily is just not a good idea :-) – metadaddy Nov 19 '14 at 0:28

Your Answer

