1

I'm working on extenral service that will use REST API. The service will make a login to Salesgforce every day and will run REST queries. From this article, it seems that I need to use OAuth2 - username&password flow as my authentication method:

Much like the SOAP APIs offered by Force.com, the REST API requires users to be authenticated before accessing the data or functionality within the Force.com organization. While it is possible to reuse the SOAP-based authentication token for REST service calls, a better option is to embrace one of the OAuth 2.0 authentication flows. In the scenario below, you will use the username-password OAuth authentication flow to pass credentials to Force.com and acquire a valid session token.

For OAuth 2.0, there is a need to create a connected App and insert more credentials parameters to my service (client key, client secret). So, before implement this solution, I want to understand why OAuth 2.0 is a better option.

  • Generally referenced article: developer.salesforce.com/page/… – Eric Aug 29 '16 at 15:48
  • but if i don't need all the features that related to the connected app (like ip range..)? there is a reason why Oauth2.0 is more secure? – user34147 Aug 29 '16 at 16:05
3

The Username-Password flow is not recommended. See Understanding the Username-Password OAuth Authentication Flow:

This OAuth authentication flow involves passing the user’s credentials back and forth. Use this authentication flow only when necessary. No refresh token will be issued.

Instead, use the User-Agent flow if you can. As a common example, you can see this in action when you use the Workbench. The user grants access, then you are given a token that you can use to access the system.

This flow is secure because the client never handles a password. Also, it's easy to revoke access to a specific connection without having to reset the user's password, especially since there's no knowledge of the password on the client. Finally, it's more convenient for users, because access can remain granted, even when they change their username or password; the token is tied to the user's Id directly.

Also see Secure Coding Storing Secrets.

Salesforce.com Integrations

External applications should not store Salesforce.com user credentials (usernames, passwords, or session ID's) in external databases. In order to integrate an external application with Salesforce.com user accounts, the OAuth flow should be used. More information about implementing OAuth can be found at here.

  • 1
    The service will make a login to Salesgforce every day and will run REST queries. In this case, i need to keep the user's credentials in my database. – user34147 Aug 29 '16 at 16:26
  • @user34147 I've added an edit. Salesforce strongly advises that you do not store salesforce credentials. If you're "caught" doing this, your app may be suspended (they can do this by way of your Connected App settings), and you will fail a security review if you take one. The username-password flow is only for development/testing purposes, and should never be done with a live system. – sfdcfox Aug 29 '16 at 16:34
  • there are cases that i'll not be able to use a refresh token? my service should be able to make the connection automatically in any time. – user34147 Aug 29 '16 at 16:37
  • 2
    @user34147 That's what a refresh token does. It actually is mentioned in the connected app as "Perform requests on your behalf at any time." The only time you "lose" a refresh token is if it expires (admin configurable) or if the user or admin explicitly revokes it. When this happens, they need to log in again. Generally speaking, these tokens are very long lived; it can even last for months or years if not revoked. – sfdcfox Aug 29 '16 at 16:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.