Expiration and Extension of Access Tokens

Facebook's official SDKs manage the lifetime of tokens for you. When using iOS, Android or our JavaScript SDK, the SDK will handle making sure that tokens are refreshed before they expire.

Native mobile apps using Facebook's SDKs will get long-lived access tokens, good for about 60 days. These tokens will be refreshed once per day when the person using your app makes a request to Facebook's servers. If no requests are made, the token will expire after about 60 days and the person will have to go through the login flow again to get a new token.

Access tokens on the web often have a lifetime of about two hours, but will automatically be refreshed when required. If you want to use access tokens for longer-lived web apps, especially server side, you need to generate a long-lived token. A long-lived token generally lasts about 60 days. This is what the process for generating a long-lived token looks like:

How to generate a long-lived token:

  1. Start with a short-lived token generated on a client and ship it back to your server.
  2. Use the user token, your app ID and app secret to make the following call from your server to Facebook's servers:
GET /oauth/access_token?  
    grant_type=fb_exchange_token&           
    client_id={app-id}&
    client_secret={app-secret}&
    fb_exchange_token={short-lived-token} 

Make this call from your server, not a client. The app secret is included in this API call, so you should never actually make the request client-side. Instead implement server-side code that makes the request, then pass the response containing the long-lived token back to your client-side code. This will be a different string than the original token, so if you're storing these tokens, replace the old one.

Once you've retrieved the long-lived token, you can use it from your server or ship it back down to the client to use there.

An important note: Apps are unable to exchange an expired short-lived token for a long-lived token. The flow above only works with short-lived tokens that are still valid. Once they expire, your app must send the user through the login flow again to generate a new short-lived token.

Refreshing Long-Lived Tokens

Even the long-lived access token will eventually expire. At any point, you can generate a new long-lived token by sending the person back to the login flow used by your web app - note that the person will not actually need to login again, they have already authorized your app, so they will immediately redirect back to your app from the login flow with a refreshed token - how this appears to the person will vary based on the type of login flow that you are using, for example if you are using the JavaScript SDK, this will take place in the background, if you are using a server-side flow, the browser will quickly redirect to the Login Dialog and then automatically and immediately back to your app again.

After doing the above you will obtain a new short-lived token and then you need to perform the same exchange for a long-lived token as above.

In some cases, this newer long-lived token might be identical to the previous one, but we can't guarantee it and your app shouldn't depend upon it.

With the iOS and Android SDKs, long-lived tokens are used by default and should automatically be refreshed.

Extending Page Access Tokens

Apps can retrieve a page access token from Page admin users when they authenticate with the manage_pages permission. If the user access token used to retrieve this page access token is short-lived, the page access token will also be short-lived.

To get a longer-lived page access token, exchange the User access token for a long-lived one, as above, and then request the Page access token. The resulting page access token will not have any expiry time.

Using Long-Lived Tokens on Web Clients

You should, in general, not use the same long-lived tokens on more than one web client (i.e. if the person logs in from more than one computer.) Instead you should use the long-lived tokens on your server to generate a code and then use that to get a long-lived token on the client. Please see below for information Generating long-lived tokens from server-side long-lived tokens.

Generating Long-Lived User Tokens from Server-Side Long-Lived Tokens

Facebook has an advanced option for obtaining long-lived access tokens for apps that:

  1. Have their own authentication system (using a username/password for example)
  2. Store, on their servers, a Facebook access token for people using it that they send to different clients (browser or native mobile apps)
  3. Make API calls from all of those clients

If your app is set up like this it should use the process described here to obtain an access token from each client to avoid triggering Facebook's automated spam systems. The end result will be that each client will have its own long-lived access token.

At a high level, this is how you can obtain a long-lived token from the client:

  1. Make a call to Facebook's server from your server using a valid and current long-lived token to generate a code. (This assumes you've already obtained a long-lived token via Facebook Login. If the token you're using is invalid or expired, you'll have to obtain a new one by making the person using your app log in again.)
  2. Securely send that code to the client.
  3. The client then exchanges the code for a long-lived token.
  4. The client can use the long-lived token to post stories or query data.

This is a diagram of the flow:

Getting the code

Using a long-lived user access token, make a call to the following endpoint:

https://graph.facebook.com/oauth/client_code?access_token=...&client_secret=...&redirect_uri=...&client_id=...

The call requires the following arguments:

Argument Required Description

access_token

Yes

Long-lived user access token.

client_id

Yes

The App ID.

client_secret

Yes

The app's app secret.

redirect_uri

Yes

The redirect URI must be set to the exact value in the app's configuration.

The response will look something like:

{"code": "...."}

Redeeming the code for an access token

Once you've retrieved the code from Facebook's server you then need to ship it to the client via a secure channel. Once that's done, you need to make a request from the client to this endpoint:

https://graph.facebook.com/oauth/access_token?code=...&client_id=...&redirect_uri=...&machine_id= ...

The call requires the following arguments:

Argument Required Description

client_id

Yes

The App ID.

code

Yes

The code returned from Facebook's server.

redirect_uri

Yes

The redirect URI must be set to the exact value in the app's configuration.

machine_id

No

An important per-client (not per-user) value that tracks clients and is used for security. If you're previously made calls to get a code and been provided a machine_id you should include it here.

The response will look like:

{"access_token":"...", "expires_in":..., "machine_id":"..."}

Returned values are:

Value Description

access_token

A new long-lived access token that you can use for Graph API calls.

expires_in

The number of seconds until this access token expires.

machine_id

The machine_id for this client. Please store this for future calls to generate a new access token from a code. This helps identify this client and is used to prevent spam.