OAuth 2.0 is “an open protocol to allow secure API authorization in a simple and standardized way from desktop, web applications“.  For many use cases (for e.g. mobile clients, browser/Javascript clients etc.), OAuth is a better alternative for authenticating users compared with the traditional username/password approach and all the Force.com APIs support OAuth. There are already some great resources available on Force.com’s support of OAuth including the basics and Pat’s excellent OAuth 2.0 article. There  is however still some confusion on a particular use case for OAuth.

If you’re familiar with OAuth 2.0, you know that it requires you to create a new Remote Access Application in your Force.com Org, which assigns a unique ‘Client Id’ (aka ‘Consumer Key’) and ‘Client Secret’ (aka ‘Consumer Secret’) to your application. Depending on the exact OAuth 2.0 flow that you implement in your client, you have to pass one or both of these values as part of the OAuth ‘handshake’ in order to get a valid Access Token. So the question is, if I setup a Remote Access Application in one Org (Developer Edition or otherwise), can I use the assigned ‘Client Id’ and ‘Client Secret’ values to only log into that particular Org? Do I need to setup separate Remote Access Applications (and get the respective ‘Client Id’ and ‘Client Secret’) in each Org that my client application needs to access?

The answers – No and No. You only need to setup a single Remote Access Application and you can then use the assigned ‘Client Id’ and ‘Client Secret’ values to have users log into any Salesforce Org – not just the one where the Remote Access Application was setup. This question is especially relevant to ISV partners that are developing Managed Package applications are are installed by multiple customers in their respective Orgs. As an ISV developer, you only have to create a single Remote Access Application in your Developer Edition Org and include it in your Managed Package. All your customers can then use that Remote Access Application to login to their respective Orgs.

I hope this has helped clarify the use of OAuth in the context of using it to log into different Salesforce Orgs. As always, questions and comments are welcome.