23

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.

Improve this question
2
  • 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
    Commented Nov 25, 2014 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
    Commented Jan 20, 2015 at 10:40

2 Answers 2

Reset to default
25

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?

Improve this answer
14
  • 1
    solid answer, this is a regular misconception of OAuth clients
    – thegogz
    Commented Nov 17, 2014 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
    Commented Nov 17, 2014 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.
    – Matt and Neil
    Commented Nov 17, 2014 at 14:49
  • 2
    You just don't use the secret with user-agent flow - see developer.salesforce.com/page/…
    – metadaddy
    Commented Nov 19, 2014 at 0:27
  • 2
    @YsrShk Note, when you click "Allow" for Workbench, salesforce deploys an Installed Package using their internal automated process user. To do the same, you could invoke the Metadata API from your app.
    – Matt and Neil
    Commented Dec 24, 2018 at 15:58
2

@mattandneil'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.

Improve this answer
3
  • 4
    Please don't collect the password from the user and use username/password flow! :-o
    – metadaddy
    Commented Nov 18, 2014 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
    Commented Nov 18, 2014 at 6:44
  • 2
    Cool. Handling user credentials unnecessarily is just not a good idea :-)
    – metadaddy
    Commented Nov 19, 2014 at 0:28

You must log in to answer this question.

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