Search code examples
intranetfacebook-oauth

redirect_uri blocking ability to make intranet-based application

I'm working on a intranet-based application that the company I work for will sell that will have the ability to post to Facebook walls as part of a background process.

To authorize, I need to go through the flow (i.e. https://graph.facebook.com/oauth/authorize with parameters client_id=1234567890 and redirect_uri=http://customer-intranet.example.com)—and it's the second one that's stymieing me, because I can't predict redirect_uri, and Facebook seems to be strict about the whole thing being pre-specified in the app.

I'm thinking I need to set up a hosted site that receives the access token from Facebook and then somehow redirects that token back to the customer's intranet site where it can be used. (And then there's the whole offline access token deprecation thing...)

Am I making things too hard for myself? Is there a better way to do this? I've looked over the other authentication flows, and of them, device might work, but it's apparently in closed beta.

Solution

  • You may consider Client Side authentication flow or using JS-SDK with OAuth Dialog, that way you may easily avoid specifying redirect_uri since it may be provided automatically by JS-SDK (or you may use current URL window.location as shown in documentatio of Client Side auth flow).

    Notes:

    While this may help you to avoid usage of redirect_uri actual problem is a bit deeper...

    Usage of redirect_uri will make such flow hard to implement not only due to inability to predict it, but due to requirement that redirect_uri should be located within App Domain, same goes for usage of JS-SDK.

    Application Settings screenshot

    So generally you will be required to place the domain name of redirect_uri / URL Application Running on in the application settings, which is nasty in case of many clients/domains.

    You may implement auth flow by using separate (publicly accessible) host but it's good to ask yourself a couple of question before doing so:

    1. Who will be responsible for that host and what will happen with all your clients if something going wrong with that host for auth only.
      • It's additional dependency which is better to avoid.
    2. Will you be albe to provide domains for all of your clients in application settings?
      • This may lead to violation of platform policies on data transfer to third parties (consult a company lawyer before doing so)
    3. Are you required to use single Application for all your clients?
      • If not you better instruct clients to set-up application and configure your application/code with credentials they got.

    Summarizing stuff:
    You can create separate application for every client or instruct client to set-up application as part of install/set-up process for you application. Later you may use Client Side authentication flow to create generic code that will work for every client (this is possible with Server Side flow too, but will require some additional work and with JS-SDK FB.login it may be a drop-in functionality without any additional work).