What is the correct way to refresh Facebook OAuth2 access token after it expires?

Question

As I understand it, this is the basic process for new Facebook iframe canvas apps using the OAuth2 API in a nutshell:

1. Redirect to (or have user click link to) app's authorization URL
2. User authorizes and is redirected to your callback URL
3. Callback uses "code" parameter to get a access token
4. Access token is used with Graph API to pull or push information

The problem is that access tokens expire relatively quickly and need to be "refreshed", so my questions are 1) how do you detect that the token has expired aside from trying to use it and simply getting an error? and 2) what is the best practice for obtaining a new token?

Currently, I just detect that there was an error trying to get the user's information with their access token, then redirect to the authorization URL again -- since they already authorized the app a blank page flashes by and they are redirected back to my app callback where I get a fresh token. It's so clunky I can't believe this is the proper method.

Solution 1

1. The only way to tell if a cookie is valid is to use it and catch the error if it is expired. There is no polling method or anything to check if a token is valid.

2. To get a new token, simply redirect the user to the authentication page again. Because they have already authorized your app they will instantly be redirected back to your app and you will have a new token. They won't be prompted to allow since they have already done that.

In short, there are no tricks to this. You are already doing it correctly.

Solution 2

Recently, facebook has made some changes to access tokens which allows them to be refreshed periodically.

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 

For more details, check here: https://developers.facebook.com/docs/roadmap/completed-changes/offline-access-removal

Solution 3

//you just need more step because the access token you are getting will expire in 1 hour
    //you can overcome this in step 5

    1-Redirect to (or have user click link to) app's authorization URL
2-User authorizes and is redirected to your callback URL
3-Callback uses "code" parameter to get a access token
4-Access token is used with Graph API to pull or push information
    5-exchange short-lived access token you just got with 60 day access token
    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
    6-after 60 day the user must login again to your app and the steps from 1-5 will be repeated.
    --the real problem you will face is how to make the user visit your app page again

Solution 4

Facebook has removed the feature of refresh the access token on the "behalf of" mode. The best and easy way is to redirect the user to facebook login page to re-oauth the app. Find facbook doc here

Solution 5

if user has already authorized your application and access token expired. you can redirect user to authentication page again. but oauth dialog doestn't show because user already authorized your application. he will redirect to redirect_url parameter you used.

View more solutions

Comments

[mtjhax]

I suspected this was the answer but I felt it was important to post this question and get some responses. There are many duplicate posts about access token expiration and iframe issues, but no one asking about this specific issue that the Facebook docs gloss over. I'll give you the nod for best answer after a day or two to let people chime in, thanks.

[Stu]

But what happens if your app or game needs to make repeated facebook API calls, for example from Javascript or Flash? You can't expect the user to be forced to reload your app every hour, at potentially critical moments in the game?

[qodeninja]

I know this is a little old so it may not even matter now, but you can use the facebook Status URL (from the Facebook API to get the status of a session)

[mtjhax]

@Toxikman it only matters when the app tries to access Facebook information for the user, and I have never seen a game that needs to repeatedly/rapidly access the Facebook API -- whatever your app is requesting so frequently, you might want to consider saving in a temporary cache.

[kitokid]

but seem like it is only helpful for new app with short lived tokens. For the existing app which uses long lived token,it is not helpful. [you pass an access_token that had a long-lived expiration time, the endpoint will simply pass that same access_token back to you without altering or extending the expiration time.]

[logan]

Yes, that is a bit of a pain. You can only get access tokens for at most 60 days.

[Tom]

It kinda stinks for "offline" use... What if a user hasn't logged in to your app in some time? Yet you still need their token to perform actions on their behalf? They should not have done away with this type of access (or phase it out, I think there's a radio button in the app settings to still use it). Speaking of all the options and changes and backwards compatibility stuff - their API is such a joke. BUT.. in the meantime, you can check that "offline access" option too and you won't need to refresh.

[Igor Čordaš]

There is a major security flaw with this since you are hard-coding (or transmitting) your client_secret from the app.

[logan]

@PSIXO - I disagree, but if you're concerned take it up with Facebook. That example URL is taken verbatim from their documentation. You can report a bug here: developers.facebook.com/bugs

[Igor Čordaš]

Yes I know it's from the documentation but misunderstood the question a little bit, actually I was doing this all in the client side code but this API call is designed to be called from the server so there will be no client_secret in client applications so the risk is reduced. Come to think of it, what could be possible exploits if someone gets client_secret and app_id. I was thinking you could send user to another page and steal the token but found out that is not possible due to only allowing sub-domain redirections after login (linked to url for the app).

[Appetere]

For step 2) in the answer, what allows the authentication page to remember the app is authorized? Does it use a cookie?