Question

I need to migrate my FB app away from using the offline_access permission. As I understand it, server-side OAuth should return a long-lived (60 days) access_token once the user has authenticated.

Once those 60 days are up, I have to request a new token. But, can I do this transparently without requiring the user to revisit Facebook? I understand that the user won’t be prompted for the same permissions, but:

a) the redirect_uri parameter must point to a URL where I can process the OAuth request, which makes it difficult for a transparent operation

b) many of my Graph API calls are initiated from AJAX requests hitting my server. If these are rejected due to an expired token, I can’t redirect the user away without breaking my application flow.

So my question is, can this be done in a completely transparent manner? I’m assuming the answer is ‘No’ but bugging the user every 60 days – especially if they’ve been using the app regularly for 59 days – seems overkill.

Answer 1

It does indeed look like the answer is “No”… Under Scenario 3

Note: The user must access your application before you’re able to get
a valid “authorization Code” to be able to make the server-side OAuth
call again. Apps will not be able to setup a background/cron job that
tries to automatically extend the expiration time, because the
“authorization code” is short-lived and will have expired.

We’re facing the same problem and it looks like we’re going to be forced to bug the user every 60 days. Thankfully this is a relatively minor part of our system and all the AJAX calls are made to our servers which in turn query fb – so we’ve got a layer of abstraction there where we can hand back cached data/control messages to manage application flow which gives us some wiggle room in terms of failing gracefully until we can get pending data stored and redirect the user appropriately.

Incidentally, it’s worth noting that according to the roadmap offline_access will officially become deprecated on 3rd Oct 2012.