Facebook Login

Access Token Portability

Updated: Jun 30, 2026
Copy for LLM
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:
  1. Native or web client authenticates and uses the returned short or long-term token to make calls.
  2. 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.
  3. 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

Flow diagram: client requests access via SDK and Login Dialog, user approves, token returns to client, then Graph API calls

Web Client Flow with Long Term Token

Swimlane diagram (Client, Your Server, Facebook): server exchanges short-lived token for a long-lived one, returned to web client for Graph API calls

Web Client Flow with Code Exchange

Swimlane diagram of code-exchange flow: server stores long-lived token, generates a code the client exchanges for its own long-lived token to call Graph API

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.
Swimlane diagram: client login, server stores the long-lived token and proxies all Graph API calls using appsecret_proof

Client Login and Client or Server API Calls

This configuration is a combination of the above approaches.
Swimlane diagram of hybrid flow: long-lived token returned to both client and server, so Graph API calls come from either using appsecret_proof

Set Access Tokens Using the SDK

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