2

We've have created plenty of REST Apex classes and access them using OAuth 2.0 using Web Server Flow (consumer secret, consumer key, etc.)

However, we're in the process of creating our first REST Apex class that a 3rd party partner will have access to.

Since our current APEX REST classes are used by our own client applications (hosted on our servers), we feel they're secured.

My question is what is considered best practice to allow a 3rd party partner to use a new APEX REST class? This class will return back one opportunity record (JSON)

My thinking is to continue to use OAuth 2.0 and do the followng

  1. Create new Connected App
  2. Selected OAuth Scopes
  3. Add IP Restriction?
  4. Provide partner consumer secret/key

Is this sufficient or is their a better secured way?

Also, is there a way to use OAuth without having to give the partner a Salesforce user account? It would be ideal to just be able give the partner an endpoint to retrieve an access token and then use our Salesforce REST Apex passing the access token.

2

That's a great question.

You already have covered a lot of details in you question summary and looks like you are on right track.

Here are the possible bits you could configure making it more secure :

  1. Connected App (oAuth 2 Web server flow)
  2. Scopes control
  3. IP Restriction
  4. Profile Setting
  5. ConnectedApp handler (Own custom keys)
  6. Mutual Authentication (Client certificate)

You already have covered most of the items and John gave bit extra details about Profile setting.

In addition to that, ConnectedApp handler could be used to verify some extra parameters, being passed in the flow, to make sure that request is coming from the correct partner, if connected app keys are compromised. You can put your own logic there at Salesforce end.

Also, you could use Mutual Authentication for Inbound API calls, to provide additional security by passing client certificate along with the request. This allows secure server-to-server connections initiated by a client using client certificate authentication, and means that both the client and the server authenticate and verify that they are who they say they are.

  • Thank you for a thorough explanation! For #5, are you referring to "Custom Connected App Handler"? – user20719 Mar 7 '17 at 16:43
  • Yeah that's correct. – Salesforcesmarty Mar 7 '17 at 23:03
  • Thanks Salesforcesmarty! BTW, I tried to test this and couldn't get it to work. Finally realized since setting partner as a community user, needed to access via community site and not login.salesforce.com. Although, one thing I'm realizing is the partner will be hitting the API throughout the day and don't want them to have to constantly authenticate (login). Should I instead give them a "refresh" token or is there another approach? – user20719 Mar 7 '17 at 23:12
2

It sounds like you are on the right track with a dedicated Connected App for (each of) your 3rd parties. Scopes and IP restrictions are a pretty good idea too.

Your really going to want to setup an "API User" for your third party, with a profile specifically and carefully tailored for appropriate access. This being the case, you really need to give you partner a Salesforce Account.

There was an article published a few years ago about setting up a Portal/Community User for API Access. Here's the link. While you will save money on licensing, you have the overhead of setting up Portal/Community, Sites, etc. Full disclosure... as interested as I am in setting something like this up, I really haven't done a full up implementation. I can say from experience that it won't work in a Sandbox.... DE or Production only.

  • 2
    +1 - use separate users for each API partner for best traceability and control – cropredy Mar 7 '17 at 2:23
  • @John Thompson. Thanks! I was afraid of that; having to create a Salesforce Account but I suspected that was going to be the case. – user20719 Mar 7 '17 at 2:37
  • @cropredy. Great suggestion. Definitely will do that for each partner. – user20719 Mar 7 '17 at 2:38

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.