Expiration and Extending 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 applications 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:Here are the steps that you need to take to generate a long-lived token:
- Start with a short-lived token generated on a client and ship it back to your server.
- 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 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:
- Have their own authentication system (using a username/password for example)
- Store, on their servers, a Facebook access token for people using it that they send to different clients (browser or native mobile apps)
- 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:
- 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.)
- Securely send that code to the client.
- The client then exchanges the code for a long-lived token.
- 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= ...
The call requires the following arguments:
Argument | Required | Description |
---|---|---|
access_token | Yes | Long-lived user access token. |
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/authorize?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. |