Apex Code Development You need to sign in to do that
Don't have an account?
vbadhwar Integrating Web Applications with SFDC using OAuth
Some web-applications require the ability to make persistent connections with salesforce.com (SFDC) for scheduling batch updates, data processing, etc. In such cases, authenticating with the SFDC Session ID will not work, because sessions expire after a period of inactivity.
The legacy method to overcome this challenge was to store SFDC usernames, passwords and security tokens within the web-application integrating with SFDC. However, there are many reasons why users should not share their private credentials. Giving your SFDC username and password to a third-party for accessing data is the same thing as going to dinner and giving your ATM card and PIN code to the waiter when it’s time to pay. Additionally, if you want to revoke access from one of the applications, you will need to change your password, which may break other integrations.
SFDC now supports OAuth to provide a secure method for SFDC customers to grant third-party applications delegated access without sharing their passwords. This is done usingtwo sets of credentials: the Consumer (web-application) identifies itself using its Consumer Key and Consumer Secret, while the User (SFDC user) is identified by a Token and Token Secret. Each set — Consumer Key-Secret and Token-Secret —can be thought of as a username-password pair (one for the application and onefor the end-user). But while the Consumer credentials work much like a username and password, the User is represented by a Token which is different than their actual username and password. This allows the Service Provider and User greater control and flexibility in granting Consumer access. For example, the User can revoke a Token without having to change passwords and break other applications.The decoupling of the User’s username and password from the Token is one of the most fundamental aspects of the OAuth architecture. A general overview of OAuth is available at: http://hueniverse.com/oauth/. SFDC specific implementation guidance is available within the 'Help' documentation once you are signed into your SFDC account (search for keyword "oauth" ).
As an ISV ("customer" ), here are some key items to be aware of:
- A consumer key and secret created in an org are global .i.e. they could be used by a user to negotiate access for that consumer to any Org, as long as the user has credentials
- A consumer key / secret can only be included in a managed package (no unmanaged package support)
- When a consumer key / secret is packaged, it can only be used with an org that has that managed package installed
- At runtime, when an access token is negotiated for a consumer that belongs to a managed package, the access token is scoped to the user's Org, with the CRUD/FLS permissions of the user as well as the package access permissions granted upon installation being enforced.
Just to get some clarification on this. If, as an ISV, I'm using oAuth to allow multiple client orgs interact with a third part service does the key in the Remote Access setting get regenerated per client org. Say I create a Force.com application that integrates with an app built on Google App Engine. Each client has an Org and an account on the app created on GAE.
So a new client uses Trialforce to spin up an Org and signs up to use my Force.com App. Do we have to hand hold them through through the process of creating the Remote Access entry or does a new key get generated, and thus prevent other client orgs mixing data. I assume that the new client is prompted to provide an SFDC login to give authorisation to allow interaction with the GAE app. If this is the case is better to create a 'service' account login for each client.
Bottom line we want to reduce complexity for the customer when they sign
Right now, you would need to make an app exchange package for your remote access settings, and have each org install it, and the client would use the same key regardless of org.
Hi Simon,
Thanks I assume the Remote Access settings could be included in the overall application managed package. That is if I deploy my application I don't need a seperate Managed Application just to take care of the Remote Application settings. Or if the Application has been deployed can it be included in the release of a new version of that application.
If I understand correctly the point is that the key is the same whether one or 100 client orgs use the 3rd party application via the Remote Access settings. Then, I assume, its just a matter of some user granting access on a per Org basis. So as part of their initial setup or upgrade we create some logic that says 'Please let this 3rd Party Application have access'...
Yes, you can package the remote access settings into a managed package.