offline access. After July 5, will desktop appl. be able to have access to FB data if user, associated with access token, logged out from FB?

Question

The situation is still unclear for me – After July 5th 2012, will desktop application be able to have access to Facebook data if user, associated with access token, logged out from Facebook? Are talking here about TOTAL deletion of offline access AT ALL or just limitation for offline access by 60 days?

Document - https://developers.facebook.com/roadmap/offline-access-removal/ doesn’t give clear answer (IMHO). Quote: “Once the migration setting has been enabled, Desktop applications will automatically get user access_tokens returned that have the longer expiration time. However, there is no way to get a long-lived user access_token without having the user login to your app again.”

As of April 30 I’m able to request access token WITH ‘offline_access’ permission for desktop application (using URL: https://graph.facebook.com/oauth/authorize?client_id=APPLICATION_ID&redirect_uri=http://www.facebook.com/connect/login_success.html&scope=manage_pages,read_stream,publish_stream,offline_access ) . And everything work fine. Even if user logged out. In spite of “Remove offline_access permission” was enabled for the application.

Your answers will be very much appreciated.

Answer 1

Just completed a patch to accommodate these changes. At least in my experience, we were working within a web app where renewing the access tokens was as simple as changing everything over to the Javascript SDK and relying on the browser's login state. This seemed a much more logical approach than cross-checking a server-side saved long-expiry access token with every action to see if it was still good.

Essentially, what is going to happen for desktop implementations is the access tokens will be longer-lived by default, but still require the renewal at the end of the sixty day period. You should have logic in your app that will check that validity of the access token with facebook before taking action with it (or just try and fail with a prompt) and then prompt the user to login and revalidate if the access_token has expired. So long as this logic is in place the access tokens that expire will trigger re-validation.

If your app receives short-expiry access tokens...

If you would like to refresh a still valid long-lived access_token, you will have to get a new short-lived user access_token first and then call the same endpoint below. The returned access_token will have a fresh long-lived expiration time, however, the access_token itself may or may not be the same as the previously granted long-lived access_token.

Short-lived access tokens, the kind that only last for a session until logout, are going to need to be converted to the sixty-day, long-expiry access tokens using the endpoint documented in that article. Desktop apps configured to the new setting will receive these kind by default, but these will still need to be regenerated with a new login after 60 days.

I agree that this is a lot clumsier to implement, especially for desktop apps, but it is certainly a lot more secure from facebook's standpoint. If you start to think of the access token as a transient rather than permanent access credential and start changing your logic to check validity via curl or some other http post mechanism, rather than referencing your database, you'll have a much easier time with the adjustment. Don't allow your architecture to assume that the presence of a saved access token guarantees access, and be sure to cross check them over to the facebook endpoints and prompt for re-login where necessary.