Access Token Portability

This guide explains some common scenarios of portability so you can build your app with the configuration to fit your needs.

Token Usage with Different App Types

Access tokens are portable. Once you obtain a token, you can use it from any machine. When you combine web interfaces, mobile clients, and servers, you can get a mix of different possible configurations. However, these different configurations come with different advantages and disadvantages in terms of capabilities and security.

Configuration	Advantages	Disadvantages	Security Notes
Login and API requests happen in a web client (short term token).	Simple implementation.	No offline posting. No long term access. Authenticate often.
Login and API requests happen in a native mobile or web client (long term token).	Authenticate less often.	No offline posting.
Login and API requests happen in a web client (long term token after code exchange).	Extra security in certain situations.	Difficult to implement. No offline posting.	Only useful in specific situations.
Login happens in a native mobile or web client. API requests happen on a Server (with long term token).	Offline posting. Add security features available with server based calls.	Client must call the server to proxy any calls.	Use `appsecret_proof` for any calls.
Login happens in a native mobile or web client. API requests happen on a server or in the client.	Offline posting User-driven posting from client	Difficult to implement	Use `appsecret_proof` for any calls made from the server.

Native or Web Client Login and API requests

This is the simplest configuration where authentication and API requests happen on the client. There are three possible configurations in this model:

Native or web client authenticates and uses the returned short or long-term token to make calls.
Web client authenticates and exchanges the short-term token for a long-term token via a server. This token is sent back to the web client where the web client uses it to make API calls.
Web client authenticates and exchanges the short-term token for a long-term token via a server. The server sends a code to the client. The client exchanges the code for a long-term token and uses it to make API calls. This configuration is rarely used.

Native or Web Client Flow

Web Client Flow with Long Term Token

Web Client Flow with Code Exchange

Client Login and Server API Calls

In this common configuration, authentication happens on the client, but all API calls are made by the server on behalf of the client. The server can use the appsecret_proof parameter to further enhance security when making calls.

Client Login and Client or Server API Calls

This configuration is a combination of the above approaches.

Set Access Tokens Using the SDK

There are different ways to specify which access token to use with an API call in our SDKs.

The Facebook Android SDK setCurrentAccessToken method has the accessToken parameter.
The Facebook iOS SDK setCurrentAccessToken method has the token parameter.
The Facebook Javascript SDK FB.api() method has the access_token parameter.