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.

We will discuss 4 different scenarios:

The token expires after expires time (2 hours is the default).

The user changes her password which invalidates the access token.

The user de-authorizes your app.

The user logs out of Facebook.

Token expires after expires time

This scenario refers to the use case where a user has authorized your app in the past, but the access token that you were issued has expired.

When you try to make Graph API call on her behalf you will get an HTTP 400 with the following error in the body:

{
error: {
type: "OAuthException",
message: "Session has expired at unix time
SOME_TIME. The current unix time is SOME_TIME.”
},
}

Scenario 2: User changes her password

This scenario refers to use case where a user has authorized your app in the past and then she changes the password associated with her Facebook account. In this scenario, when you try to make Graph API call on her behalf you will get an HTTP 400 with the following error in the body:

{
error: {
type: "OAuthException",
message: "The session has been invalidated because
the user has changed the password.",
},
}

Please note that you will receive this message even if your app was granted the offline_access permission if the user changed their password.

Scenario 3: User de-authorizes your app

This scenario refers to a use case where a user has authorized your app in the past, but then she de-authorizes your app by going to the App Dashboard. In this scenario when you try to make a Graph API call on her behalf you will get a HTTP 400 with the following error in the body:

Please note that even if the user had authorized your app with the offline_access permission access tokens will become invalid if the user de-authorizes your app.

Scenario 4: User logs out of Facebook

This scenario refers to a use case where a user has authorized your app in the past and then she logs out of Facebook. If the user authorized your app with the offline_access permission then the Graph API call works as expected. If the user did not grant this permission and you try to make a Graph API call on behalf of the user, you will get an HTTP 400 with the following error in the body:

To ensure the best experience for your users, your app needs to be prepared to catch errors for the above scenarios. The following PHP code shows you how to handle these errors and retrieve a new access token.

When you redirect the user to the auth dialog, the user is not prompted for permissions if the user has already authorized your application. Facebook will return you a valid access token without any user facing dialog. However if the user has de-authorized your application then the user will need to re-authorize your application for you to get the access_token.