I am looking for help/advice on handling expired tokens (eg. user changes password) in conjunction with the realtime api. I have read the following http://developers.facebook.com/blog/post/2011/05/13/how-to--handle-expired-access-tokens/
but it appears to require a user session. Currently the only solution I can see is detecting the OAuth error and informing the user via another means such as email that they need to go through the app authorisation process again.
you can renew the fb access token, there is the feasible solution for this, kindly have look into how-to--handle-expired-access-tokens here, you can see the answer in Solution (for all scenarios) section
Related
Should the limited login store the access token for future session?
I'm transferring my iOS app from classic login to limited login. But I can't get the auto-re-login to work.
Re-login with classic works correctly as docs says. "The FBSDKLoginManager sets this token for you and when it sets currentAccessToken it also automatically writes it to a keychain cache." The app r-logins correctly.
But with limited login it seems it doesn't store the token. Should is store? The docs are unclear whether limited login should do this or not.
Best, Hu
Let's start with some points to proceed:
Limited Login mode doesn't provide you an Access Token. It provides you an Authentication Token. It's a regular JWT you can parse, but you are not able to use it for FB Graph API requests;
You can get the basic information about the user just by decoding this Authentication Token or using FB SDK right after signing in;
Currently, this token has an expiration of 1 hour, but you don't really need to refresh it every hour unless you need to get an update of the user information (for instance, to fetch a changed name, email, or a list of friends);
As you can see in the official blog post of Facebook, to refresh a token with information inside it, you need to re-authenticate a user, so call an SDK method to show FB popup. Reference: FB: Announcing expanded functionality in Limited Login
Currently, the official documentation is really unclear and has just a couple of pages related to the Limited Login mode. So if you still have any other questions, feel free to ask, I'll update the post.
I'm implementing a connect with Facebook/Twitter/... functionality on a website. The idea is that once a user connects his account with the external services our website could post messages on behalf of the user.
With Twitter there is no problem as the OAuth access_token doesn't expire. But with FB it does expire every two months, when the user logouts, changes password or explictly deauthorizes the app.
How should I handle the token expiration? For me it would be ideal if I could refresh the token automatically without bothering the user, but unless I've missed something it seems there isn't any way of doing this. So, right now I've two ideas:
The less akward way: every time the user logins to the website check if the tokens have expired and notify the user that she has too reauthorize the app.
The more akward way: every time the "post to social networks" event triggers in our website, check if the tokens have expired and ask the user to reauthorize.
The first option would be easier to implement and cleaner to the user.
So, how are you handling this situations?
Thanks!
I think that I'll trye the first option:
User logs in
The server checks if the user has already a Facebook token, if so:
Check if it's still a valid token. http://developers.facebook.com/docs/howtos/login/debugging-access-tokens/
If the token expired NOT because the user deauthorized the app BUT because the other cases we redirect the user to the OAuth endpoint.
I'll give it a try and update this answer if there is more to it.
If the user is actually interacting with your website, you should be getting a fresh access_token (read below). If you perform offline tasks related to the user using the Facebook API then you should be storing the access_token and their expiry dates. Then you need to handle expired access tokens and ask the user to interact with your app again and update your records.
You should refer to this document. Also you should be reading the Extending Access Tokens document:
Step 2. Refreshing Long-lived User Access Tokens
At any point, you can generate a new long-lived token by repeating the
original auth flow, obtaining a new short-lived token and then
performing the same exchange as above. In some cases, this newer
long-lived token can be identical to the previous one, but we do not
guarantee this will be true and your app shouldn't depend upon it.
On my app the user can sign to Facebook and the app then has the user's access token (say it's 'abc'), I want to use this token to create a user on my own server.
Is it safe to send this access token to my server (using SSL), then get the user's username and ID using https://graph.facebook.com/me?access_token=abc on my server and check that the application the token belongs to is mine with https://graph.facebook.com/app?access_token=abc. If it is my application I then store the user in my user's database and/or log them in.
Can this system be fooled? Can you think of a way someone could log in as someone else?
You should check out all of the Authentication documentation and the Oauth spec to see the different auth flows available
Broadly speaking, you can create a user on your server based on the access token, and be reasonably certain that when you get an access token from Facebook for the same user ID that it's the same person.
If you require very high security for the app you can take steps to ensure the user's access token wasn't produced via malware or the Facebook user being tricked, there's an example showing protection against CSRF in the Server Side Authentication documentation, and there's also a reauthentication flow you can use
I assume that you are using facebook sdk for this, if so the facebook sdk takes care of the security for you and you don't have to worry about a thing.Supposing that you are accessing the api without the sdk then there are two things that must be noted:
1) Auth token expires frequently(facebook has taken great pains to ensure that the user is protected)
2)Making a request with just auth token is not enough there are some other parameters that are needed that can't be faked especially if you are doing this server side since an extra layer is added that fb calls server flow authentication
3)On top of that there are a lot of permissions that are in place that the user has to give in order for an application to access some data.The link below provides a nice article on authentication you can take a look
https://developers.facebook.com/docs/authentication/
So long story short it is safe.
I can request an access_token upon supplying an offline_access scope parameter to oauth. I can execute OpenGraph commands that require an access_token just fine when logged out of Facebook, and when I log back in, I don't need to create a new one.
According to this blog post, offline_access is (getting?) deprecated.
Confusions:
Why doesn't the authentication dialog display that I am requesting offline access when authenticating a user?
Is it currently safe to rely on persistent access_tokens?
Clarification greatly appreciated!
The Facebook API generally shouldn't be accessed when the user isn't online. You can update the access token anyways, and that should be good enough.
From: http://developers.facebook.com/blog/
There are no changes required for most apps, but developers utilizing
the 'offline_access' permission will have until May 1, 2012 to update
their apps.
You have some time....
I'm working on a site that is trying to handle realtime feed updates from its users' Facebook accounts. I have the basic stuff in place: the app is subscribed to "feed", and the user's login asks for read_stream and offline_access (just in case) permissions. My test users have logged into FB and granted those permissions, and, when one of those users adds (or removes) a status update, the callback specified in my site's subscription is pinged. So far, all's well.
Now -- as I understand it -- my callback has to call up to Facebook to get the user's feed, so that the callback can do whatever it's going to do with it. That's where I'm having problems -- finding the right access token to retrieve the feed:
I've tried doing this with the app's access token. This token is able to retrieve friend information (also included in the app's subscription and user permissions), but it won't get me the feed.
I've tried all sorts of ways to get the user's access token from inside the callback, but nothing is working. I'm guessing this is because it's not "logged into Facebook" the way that a user in a browser can be, but whatever. Bottom line is I haven't found a way to get this token.
(BTW, if I cheat -- get an access token for the user from Graph API Explorer and hard-code it into the callback, the callback works properly. This is no real solution, of course, but it at least establishes that the rest of my code is working.)
So how does this work? Can the app access token be made to work somehow? Is there in fact a way for the callback to get an access token for an arbitrary authorized user? There's gotta be a way to do this, or there would be no point for realtime feed notifications. Any clues out there? This is SERIOUSLY kicking my butt... Thanks!
You might want to look into this. Instead of taking permission for offline access, facebook now gives short-lived access tokens (2 hours) when the user logs in. These can be exchanged with long-lived access tokens (2 months). Check out this article on how to go about it.
https://developers.facebook.com/roadmap/offline-access-removal/
I've found a solution, perhaps: When the user logs in, I snag their offline_access-enabled access token and save it in the app with the rest of the user's data. Then when I get notified of an update to that user's feed, I can pull the token from the database and pass it over to FB as the token part of the /feed... call. And, it works. There is no doubt some error handling to be done, but I am currently bouncing back and forth between thinking that (a) this is exactly the right way to handle this and (b) it's a terrible hack that is just asking for trouble. I guess I'll see which of these is the case...
Ask for offline_access (as you do) and store the access token. This is exactly why offline_access and access tokens are there, to make requests to facebook in the name of that user. (a) is the right way to go. (a) is the way I do it.
Good luck
When the user is authenticated via OAuth Facebook returns an access-token, but it is valid for few hours. The validity of this token comes with it as token-expiry.
However, this token can be exchanged with a new extended token which is valid for around 60 days. User the following code to get new-token:
URL url=new URL("https://graph.facebook.com/oauth/access_token?grant_type=fb_exchange_token&client_id="+appId+"&client_secret="+clientSecretId+"&fb_exchange_token="+fb_exchange_token;
InputStream Istream=url.openConnection().getInputStream();
BufferedReader br = new BufferedReader(new InputStreamReader(Istream));
String new_token= br.readLine();
Hope it helps!!