Facebook 401 and access_token - any cool ideas?

[yonimoses]

Hi,


What's the best approach of refreshing access_token for users in FB?
I know I can check for the 401 exception and handle myself in the conenction flow (e.g - redirect again to FB and start the authorize flow again) , but I was wondering if that the best practice?

Is there any solution for renewing the token everyday ? (now that the offline_access is dead?)

[habuma]

Good question. Unfortunately, I still don't have a good answer for that (but I am working on it).

Facebook's killing off of offline_access is a *GOOD* thing. Their approach is quite a bit closer to what the OAuth 2 spec does with refresh tokens (essentially, using the access token as its own refresh token). But, I still don't have a good answer for you on the *best* way to do this.

Certainly one way to do it (albeit cumbersome) is to directly query the UserConnections table to get the access token and then use RestTemplate to directly do the refresh yourself...followed by updating the UserConnection table, if necessary. That will work...but it's certainly not the best way to do it.

I'm also not certain that I would refresh every day...what if the user hasn't used your application in several weeks? Then you're refreshing for no reason. I'd tend to refresh only on realization that the token you have is no good.

This is a good opportunity for discussion on the topic, though. My thinking is that this would be handled much the same way as refresh tokens, only with a Facebook twist. I'm always open to ideas on how to do this, though.

[yonimoses]

Since I'm using the UserConnections to persist the connections, for now I'm just checking for 401 and if not valid, I'm deleting the connection. This is a very *BAD* approach, since this means that the user has to click the connect again my popup appears again.. (but since the app is already authorized, FB returns a new token and the user doesn't have to click anything.)

I thought about doing a "scheduled" refresh as you suggested but this means I'll refresh lots of tokens for no reason..

Can I use the expiretime column? if so, I can schedule a refresh on each expire token. (though I see some records have expiretime and some not..)

Do you think that in the future spring will handle refreshing of tokens?

[habuma]

Yes, it's slated for Spring Social 1.1.0 M2 to handle automatic refresh of tokens. The Facebook approach throws a wrinkle into this plan, but I'm still thinking it will be covered.

Regarding scheduled refresh of tokens, I found this yesterday at https://developers.facebook.com/road...cess-removal/: "Note: The user must access your application before you're able to get a valid "authorization code" to be able to make the server-side OAuth call again. Apps will not be able to setup a background/cron job that tries to automatically extend the expiration time, because the "authorization code" is short-lived and will have expired."

In short, Facebook doesn't want you to do automatic refresh. The user has to be involved, they say.

The best and most appropriate strategy for refreshing tokens is to do so in response to the realization that the token has expired. Spring Social's OAuth2Operations interface supports this via the refreshAccess() method. The refreshAccess() method is called from the refresh() method on the connection...so if you can get the connection object, you can call refresh() upon finding out that the token has expired.

This, of course, is based on the OAuth 2 spec and not on Facebook's refresh approach--so it doesn't help you much right now. Fortunately (or unfortunately, depending on your perspective), I've already had to create a special subclass of OAuth2Template for Facebook's quirks, so it looks like I might have to override the refreshAccess() method in FacebookOAuth2Template to deal with this problem, too.

[habuma]

Every time I read the stuff at https://developers.facebook.com/road...cess-removal/, I end up more confused than I was before. Therefore, I've posted my questions to Facebook at their Stackoverflow site: http://facebook.stackoverflow.com/qu...narios-3-and-4

In short, I am now led to believe that this new strategy is *nothing* like OAuth 2 refresh tokens and probably much better described as offline_access with a 60-day expiration.

The key difference between this strategy and refresh tokens is that with Facebook you may only reset the time of a token that has not already expired; with OAuth 2 you can refresh an expired token. Thus, my initial thinking of how to resolve this is probably not good because by the time you recognize that the token has expired, it's too late to "freshen" it.

At the same time, they don't want you to keep freshening it on a schedule, so portions of that document indicate that you should freshen it when the user accesses your app. I guess, upon initial signin or some other "startup" case, the token is refreshed. They didn't make it clear what was meant there, though....and if care is not taken, then you could end up (in an extreme case) attempting to refresh upon every interaction with Facebook (not desirable).

All that said, I'm eager to hear the answers to my questions and willing to hear any other interpretation you may have of the document.

[yonimoses]

I can understand your confusion.. I'm reading the docs and sometimes have no idea what the mean (almost as it seems like FB developers only worked @ FB and no other place)

From what I understand from the doc we need to call fb once a day per user (" first time requested") and request a long-lived token. the only question is how to get the expiration time. (Does FB send an expiration date for the tokens? )

my confusion is that they state the short-lived in valid for 1-2 hours - but from my production I've seen that the tokens are valid to ~10 days or so (which is consisted with some jira issues I saw in spring-social)


Actually, your idea with the "startup" is a nice one. doesn't solve all the problems but it's a start for sure.

As for spring api - any chance of tuning the API to return exceptions on the test() (like 401 or something similar) so we'd know when to refresh? right not I'm doing an educated guess...