Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best Practice for Salesforce.com API authentication for background apps

The Salesforce.com API seems to assume that you will always use the app as an active user. Their authentication methods (Session ID and OAuth) support this as they both require an authenticated user to "do something".

What is the strategy for when you have a background app that needs access to the API? The examples that I have seen ask for your full credentials - user name, password, and security token. Not only do I not want to know or store that information, but it can change (from password policies, etc) and I'd rather not have the app break because of that.

What is the "best practice" for long lived authentication to SFDCs APIs that does not require user interaction?

like image 971
Ryan Elkins Avatar asked Apr 02 '12 17:04

Ryan Elkins


1 Answers

Salesforce.com API requests operate in the context of a user, identified by a sessionId (aka access_token) (unauthenticated custom APIs exposed via sites is the one exception).

So in order to make API calls, you will need a sessionId, you can get one as you say by storing the username/password/security token and calling login (or the oauth2 username/password flow) when you need to.

Alternatively you can use the interactive OAuth flow, which requires the user to just once authorization your application, at which point you'll be given a long lived token called a refresh token. At any point after that you can use the oauth2 token service to get a new access_token (which can then make API calls) using just the refresh token.

Seems like this last approach would best meet your needs, this would require just a one time user interaction to initially authorize your application.

like image 64
superfell Avatar answered Oct 02 '22 18:10

superfell