Portability: Using Tokens with different App Types

Access tokens are portable. This means that once you obtain a token, you can generally use it from any machine - server, client or otherwise. 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 trade-offs in terms of capabilities and security. We cover some of the more common scenarios here so you can build your app with the right model.

This chart contains a comparison of several different configurations. Details about the configurations covered in this chart are below.

Configuration Advantages Disadvantages Security Notes

Login happens in a Web Client.

API requests happen in a Web Client (short-term token).

Simple to implement.

No offline posting, no long-term access, must auth often.

Login happens in a Native Mobile Client or a Web Client with Long Term Token.

API requests happen in the Client (with long-term token).

Auth not required often with long-term token.

No offline posting.

Login happens in a Web Client.

API requests happen in the Web Client (long-term token after code exchange).

Extra security in certain situations.

Harder to implement. No offline posting. Shouldn't be used in the usual case.

This is only useful in very specific situations See the docs below for more information.

Login happens in a Native Mobile Client or a Web Client.

API requests happen on a Server (with long-term token).

Offline posting. Takes advantage of security features available with server-based calls.

Client must call the server to proxy any calls.

You should use appsecret_proof for any calls.

Login happens in a Native Mobile Client or Web Client.

API requests happen on a Server or in the Client.

Offline posting. User-driven posting from the client.

Implementation can be complex.

You should use appsecret_proof for any calls you make from the server.

Login on Native or Web Client, API Calls from Native or Web Client

This is the simplest model where the auth is done on the client all calls also run through 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, exchanges the short-term token for a long-term token via a server, token is sent back down to the web client and then the web client and makes calls with the long-term token.
  3. Web client authenticates, exchanges the short-term token for a long-term token via a server, server does code exchange and the client exchanges the code for a long-term token, makes calls with that token. (Used rarely.)

Native client or web client makes API calls with token:

Web client makes API calls after exchanging the short-term token for a long-term token:

Web client makes API calls after code exchange for long-term token (Rarely used):

Login on Client, API Calls from Server

This is a very common configuration where the auth happens on the client, but the server makes all calls on behalf of the client. The server can use the appsecret_proof parameter to further enhance security when it makes calls.

Login on Client, API Calls from Client or Server

This is a hybrid of the above approaches. This is listed here so you can see that it's possible to combine these approaches depending on your use case.


Changing SDK Access Tokens

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

  • The Facebook SDK for Javascript's method FB.api() can take a parameter access_token.
  • The Facebook SDK for iOS has a setCurrentAccessToken method on the FBSDKAccessToken class.
  • The Facebook SDK for Android takes an access token as a parameter to the AccessToken.setCurrentAccessToken method.

Security Note: in all above cases, the code can be directly viewed, either by reading the HTML source or by decompiling an app binary. Therefore, your app should never have an access token hard-coded into it. Instead, calls could be made directly with the response from the access token generation request.