How-To: Handle expired access tokens

Regarding to the recent “Invalid Access Token”, many developers have been asking for proper way or sample code for handling “invalid access token”.  I think Facebook has listened to the public voices.

Today, Facebook has published a new document “How-To: Handle expired access tokens“. I think this is an action that Facebook has taken regarding to the recent “Invalid Access Token”, in which many developers are asking for proper way or sample code for handling “invalid access token”.

Extracting from the doc,

One of the most frequently asked for “How-To” requests from developers is how to handle invalid access tokens. Access tokens for users can become invalid due to various reasons. In most cases, they can expire if it’s past the time specified by the ‘expires’ field (by default access token have a 2 hour lifetime). What many developers do not realize is that an access token can also expire if a user changes her password, logs out or if she de-authorizes the app via the App Dashboard. It is very important that your apps handle such situations. If your access token expires, you need to reacquire a valid access token.

This post will walk you through how you can ensure that you are handling and recovering from these situations gracefully. It assumes that you are familiar with our server-side authentication flow.

This How-To is information and I would strongly recommend reading it.  Yet, I have some  comments.

Even if you are familiar with Facebook’s server-side authentication flow, please go through that doc page again and pay attention to the sample code there. Otherwise, you may not be able to fully understand the sample code.

I would say that the “solution” suggested in the How-To is just another sample code on how to get the access token and should not be taken as a solution.

  • In particular, pay attention to the fact that the code is working based on the “code” param in the HTTP request. Even if you are following the suggested sample code in Facebook’s server-side authentication flow, I wonder if you would carry that “code” param in every request sent out from your application.
  • In fact, if you are flowing that server-side authentication flow, you should already get the access token and this piece of code should not be required.
  • If the user de-authorizes your app after the authenication flow is completed, I think this “solution” would not work as it does not handle the reauthorization.  I am confused why in the code comments, Facebook mentions that “if we get a code, it means that we have re-authed the user and can get a valid access_token”. I think “re-authed” simply refer to the case where the user is re-authed your app when he re-visit your app again after he de-authorized the app.  However, my 2nd point (i.e the above point) applies in this case.

I am not blaming Facebook.  In fact, it is really hard to get a general, bullet-proof and simple solution for all scenarios for different applications built by different developers!

Know your application and by building an infrastructure layer / common code rountines / error handling code, it should not be that difficult in getting a reasonable solution that can handle most of the commonly encountered cases.



This entry was posted in Authentication, Development Tips and tagged , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *