Best Practice for Salesforce.com API authentication for background apps

Question

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?

Charleen

Honestly, I have the same problem. Every 90 days, we have to go in and update our SF applications' passwords because SF requires it. Real PITA. – Viand

Can't you just create an API only user with modify data and a password that never expires? Or does it need to do other things besides just API access? – Braeunig

I'm creating the app that would ideally be used by others, so this is something I would have to ask everyone to do. SFDC user accounts are expensive so this isn't a very attractive option. Also, I think the password policy is set at the org level, not the individual level. – Charleen

This might help (it did for me) salesforce.stackexchange.com/questions/90110/… – Panpipe

Answer 1

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.

Hypopituitarism

Thanks, I'll look in to the interactive OAuth flow. I'm OK with a one time authorization (in fact, I would expect something like that), I just can't require them to authorize every single time. – Charleen

Here are some links for the methods you mentioned: na1.salesforce.com/help/doc/en/… and na1.salesforce.com/help/doc/en/… – Charleen

Answer 2

Unfortunately you need to use an account to access the SF APIs. In the beginning I thought the purpose of creating a Remote Access was to avoid doing this, but alas, it is not.

Not sure if what I'm doing is a best practice way of doing things, but I am using an API specific user we created for this purpose and storing the credentials in the configuration file and encrypting the password using DPAPI. I am using SOAP WS so I call login(username, psswd) and I use that session id in subsequent calls. You could alternatively get your session Id by using OAuth 2.0, but this requires you to create a Remote Access application and you would still need a username/password.

Eustazio

Answer 3

OAuth 2.0 web server authentication is best suited for the current use case.

https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_web_server_flow.htm&language=en_US

Alejandrinaalejandro