We are in the process of implementing an outbound OAuth integration to a third party app. Our customers will, from our managed package, OAuth authenticate to the third party app and we will then use the token (via Apex) for API operations to that third party app on our customer's behalf.
This third party app has asked us for our callback URL. Since the outbound OAuth is occurring via Apex, our customers will have a different callback URL based on their SFDC instance (e.g. https://ns.ap1.visual.force.com/apex/mycustomoauthcallback). When you add up the prod and sandbox instances, there are about 40 total possible callback URL's.
When I asked them about this, they didn't have an answer for the right way to manage this.
How do other people do this? Do you get a separate app ID per SFDC URL? Do you somehow pass your instance/URL to the third party app? Do you use some fixed callback service that is hosted outside of Salesforce?
(If these are stupid questions, let me know – this is my first outbound-from-Salesforce OAuth integration.)
EDIT: I, of course, do not need 40 endpoints – just 2! The login.salesforce.com for production and test.salesforce.com for sandbox. So I think I'm in good shape, even if the third party only allows one callback per API app I'll just have two different app ID's depending on environment.
Best Answer
I did manage to get oAuth working with Google previously, but I don't remember what I did with regards to the callback. Either I hardcoded it (it was just a test) or didn't use it. A lot of oAuth systems allow you to use 'oob' which is 'out of bounds', and rather than being automatic you have to get your user to click a button in your UI once they've authenticated and granted access in the provider's UI.
I used the same approach in a Haiku terminal application, it displayed a URL for the user to put in their browser, they authenticated and authorized and then had to return to the console and hit enter to continue. The subsequent request for a session token works because you use the same authorization token that was passed originally and was approved by the user.
The first request you make will be to an authorization URL using your key and secret and that will return a response token.
The next request, once the user has authorized and hit a button to let you know, is to a request an access token, to which you pass the response token you received along with your key and secret. The response token you received is known to be good by the server and hence it provides an access token to you.