Facebook access token: server-side vs client-side flows

Question

Facebook docs:

Facebook Platform supports two different OAuth 2.0 flows for user login: server-side (known as the authentication code flow in the specification) and client-side (known as the implicit flow). The server-side flow is used whenever you need to call the Graph API from your web server. The client-side flow is used when you need to make calls to the Graph API from a client, such as JavaScript running in a Web browser or from a native mobile or desktop app.

What is the difference between access tokens taken by these flows? It seems like they length differ.

Can we use server-side flow token on a client? And otherwise, can we use client-side flow token on a server?

Solution 1

Currently, Facebook says this about access_tokens. On Server-side OAuth

if the access_token is generated from a server-side OAuth call, the resulting access_token will have the longer expiration time by default. If the call is made while there is still a valid long-lived user access_token for that user, the returned user access_token from this second call may be the same or may have changed, but in either case the expiration time will be set to a long expiration time.

Where as client-side OAuth flow will give you a existing, non-expired, short-lived user access_token. To make this access_token long lived, facebook is providing a new endpoint that exchanges the short lived access_token with an access_token with longer life. The endpoint is

https://graph.facebook.com/oauth/access_token?             
    client_id=APP_ID&
    client_secret=APP_SECRET&
    grant_type=fb_exchange_token&
    fb_exchange_token=EXISTING_ACCESS_TOKEN 

Also please note that

Currently the long-lived user access_token will be valid for 60 days while the short-lived user access_tokens are currently valid from 1 to 2 hours.

Excerpt from https://developers.facebook.com/docs/roadmap/completed-changes/offline-access-removal/

Solution 2

For those that like me are facing the same issue in 2014, Facebook improved the documentation on access tokens.

Tokens are Portable

One important aspect to understand about access token is that they are portable. Once you have an access token you can use it to make calls from a mobile client, a web browser, or from your server to Facebook's servers. If a token is obtained on a client, you can ship that token back to your server and use it in server-to-server calls. If a token is obtained via a server call, you can also ship that token down to a client and then make the calls from the client.

(from https://developers.facebook.com/docs/facebook-login/access-tokens/#portabletokens)

So yes, you can use access tokens from the client on the server and vice-versa; as already stated by naveen, the difference is that client-obtained tokes are short lived, whilst server ones are long lived. You can also convert a short-lived token to a long-lived token by following the directions here: https://developers.facebook.com/docs/facebook-login/access-tokens/#extending

Solution 3

Token can be used to make API calls since it represented that you are authenticated and authorized to do something.

Code can not be used directly to make any API call. It must be first redeemed with your app secret to get a token.

In other words, code is like an encrypted token that only parties with app secret can decrypt it.

BTW, your app secret should only appears in your server code, never in mobile or web client.

The video basically explains all this at around 13:00 https://developers.facebook.com/docs/facebook-login/security

Comments

[alexey]

Thanks for your answer. Found more info here: developers.facebook.com/docs/reference/api/permissions

[naveen]

please do not down-vote this answer. it was correct then i guess.

[drogon]

Not necessarily the same --that's a big generalization. Server side tokens are longer lived that client side ones.

[Gustavo Gondim]

This page link real does explain a lot about the Access Tokens.

[Brmm]

Whats the best way to send the access token to the server, just a plain ajax call after the client side auth? This takes a few seconds though. I tried to parse the signed request from the cookie on the server side but there's no value for 'access_token'

[gabriele.genta]

I'm currently doing this in an HTML5/Cordova app with an ajax call, and the extra round trip time doesn't impact much on the user experience. It may vary based on how you're using it, but you can usually mask the extra delay in the login procedure, maybe displaying a loader or something.

[mabi]

@Naveen can you please clarify if and how the first paragraph is still relevant?