6

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.

Improve this question

1 Answer 1

Reset to default
2

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.

Improve this answer
5
  • I can see how that would work - sorta like console apps where you have to enter a 5-digit code after OAuth, I suppose. It's definitely less preferable than a streamlined flow that doesn't take any more work from the client though...
    – jkraybill
    Jun 13, 2013 at 1:28
  • Yeah, you shouldn't need them to enter anything, just click a button to let the app know it can make a second request. Your code only provides the same info the second time around but now the server knows the context and that it has been approved.
    – Matt Lacey ♦
    Jun 13, 2013 at 1:34
  • How does the third party API server know that a subsequent request comes from the user who just authenticated? I thought in OAuth you must get a session token from the IDP; in my initial redirect I'm just passing an App ID (which is the same for all users in my app). In console apps, that 5-digit code is used in an API call to retrieve the OAuth token; doesn't there have to be an equivalent step if you don't have a callback URL?
    – jkraybill
    Jun 13, 2013 at 1:43
  • When I did an integration with DropBox the initial request (which generates the URL for the user to visit) provides a token (the response token above) which is what you pass in the second time after the user has authorised.
    – Matt Lacey ♦
    Jun 13, 2013 at 2:06
  • Really helpful, thanks. I see that Dropbox supports passing in an "oauth_callback" parameter (standard OAuth 1.0 parameter), and that the 2.0 spec supports a similar "redirect_uri" parameter. I'll work with the vendor on seeing if they support that.
    – jkraybill
    Jun 13, 2013 at 3:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .