First of all, I'm sorry for yet another "offline_access" question, but I blame Facebook for being so vague about this. I've been reading so much (here and the official Facebook deprecation "docs") about it and the more I read, the more questions I have.
Our application uses the Facebook API to publish stories from users to their timeline. This is being done from our servers using PHP via curl.
My understanding is that accesstokens cannot be valid for more than 60 days. Does this mean that our users have to come back to our site to re-authorize everytime their token has become invalid? If so, how would services like Foursquare (who have a similar integration as we have) handle this?
Or is it possible to simply request a new token when the Facebook-API replies with a "This token has expired" message?
I think this is covered in the migration document as scenario 3 or 4 depending on your auth flow
Yes, your users need to come back at least once every 60 days in order for you to have a valid token to take actions on that user's behalf
Of course they have to come back – that’s the whole point of removing offline_access, that apps can’t go on acting forever on behalf of users who maybe don’t even notice it any more.
Or is it possible to simply request a new token when the Facebook-API replies with a "This token has expired" message?
Not without user interaction. But as far as I understand it, it should be enough to call for example FB.login via the JS SDK when the user is on your page, which will display the popup and immediately close it again if the user is logged in to FB and has still authorized your app, to get a new short-lived access_token, which you can then exchange for a long-lived one.
Related
I've searched a lot and I see that offline_access on fb is deprecated. So, I have a website hat needs to Post a photo at the Client's wall (Post at site and Facebook too), but I want to store the login data (via token or something like that), I read here that I can't store it.
There is another way to post on wall or my client will need to Post manually on his fb?
Edit: My website is in one server, the admin is in another server, I'll make a call from admin server to site in a page that stores login information (if it's possible) and post on his wall a photo.
Thanks
Note: I've searched a lot since yesterday I didn't found anything like that, if you have a similar post with the answer please let me know.
If you have the user's access token you can use that token to perform activities on his behalf.
But the point here is- this token expires in 2 hours. But, you can extend this token upto 60 days. But after that, user needs to visit your app again to get the normal token again and you can then refresh that token to extend its validity again.
You can read Expiration and Extending Tokens section in this doc: Access Tokens
(Just a suggestion) What you can do anytime user visits your app, extend it save on your server. So, the token wont expire until and unless user didn't visited your app for 60 days. And when you are close to 60 days send him some notification.
I am using the stock SDK for php/javascript. Now the app I am building many parts of it, if a user approves the use and accepts the permissions acts as a layer on top of facebook. Where it is planned to have my App pretty much interact with it as if the user was logged on at the time.
Previously I was playing with the offline_access but I recently read that that permission is coming out of the api completely and soon enough any tokens already in existence will just convert to 60 day tokens. I know from what I read that I can renew the tokens on a daily basis if need be when a user logs into my app. But my two biggest questions that I can't figure out one way or another is.
How do I ensure I get the "long-lived" tokens, and with these tokens do I store them on my end and pass them through the api to FB or is facebook storing these and through the use of the api the way it is and I don't need to store them somewhere. I know currently when I login it generates a token and stores it in a php session but the session is usually only good for the duration of the user being on my app. Note this is also a desktop app, not an app within facebooks canvas.
If I have to store the tokens to use them, and the php sdk bases itself off of whats stored in a session do I recreate the session with the stored access token for the user or I dunno, Im confusing myself as I type this out, hopefully someone can shed some light on the subject for me.
Here you can find some help on how to handle the expired tokens,
https://developers.facebook.com/blog/post/2011/05/13/how-to--handle-expired-access-tokens/
And here more info on how to use the new method,
Facebook offline access step-by-step
All this matter always makes me doubt as well, but I have noticed that facebook usually keeps the token somewhere on the user end, probably a cookie, so that it will automatically connect. So I don't think that the token only lasts a session and I'd rather say you won't have too many problems with the depreciation of offline_access, though this might just be my personal opinion.
I am working on integrating Google Apps into my PHP app. I have already a login system that assigns a session ID to a user (after entering username and password), which gets stored in the database when the user is logged in. Session ID's become invalid after a certain time of inactivity (configurable by the user, can be 5 minutes, 15, 60...). That session ID is passed in the url to check if a user is still logged in. When logging out, the session ID is removed from the database.
I let people log in with Google by storing their Google ID in the database, when they log in, I request an access token, query the userinfo, see if the google ID is in the database and if so, assign a session ID to this user. Since I want to be able to query other API's I also store the access token json in the database. When a user logs out, the access token is also removed from the database.
This works, my users are able to log in using their Google account and I can query the API's using the stored access_token, however some things feel clunky of make me feel uncertain about my workflow:
If you force_approval you get a refresh_token, I feel like I should be using this refresh token to get a new access token, instead of removing the old one from the database and entering a new one when the user logs in again. On the other hand, when logging in, I do not know who it is yet, so I don't know which refresh token to use. Maybe I'm misunderstanding what the refresh token is for. Also, I don't really want to force approval every time, so I can't even use the refresh_token in that case.
As said before, users can determine how long their session will last, however, the google access_token always expires after 3600 seconds. It'd be really stupid if users would work an hour on the system and after that the Google API's suddenly fail, forcing them to log in again. The Google OAuth playground shows a checkbox "Auto-refresh token before it expires", but I'm not seeing how to do this. Do I have to use the refresh token here? Or simply request a new token in the background (if I'm not forcing approval)?
At the moment, I'm using the userinfo query (https://www.googleapis.com/oauth2/v2/userinfo) to find the user id, but I can also use the tokeninfo (https://www.googleapis.com/oauth2/v1/tokeninfo). Tokeninfo is not listed in the oauth playground, but the result does show how long the token remains valid (however, I can also calculate this myself). Is one preferable over the other?
I'm storing the entire json object in the database (access_token, id_token, expires_in and token_type) but I feel my app will still work perfectly if I only store the access_token (only problem I foresee is if the expires_in time changes). Do I need to store the id_token for example?
I find the Google documentation (at developers.google.com) sometimes very lacking, if anyone knows any other good sources of information, I'm interested in them as well.
I think it might help if you took a look at the lastest OpenID Connect Specs where concepts like the userinfo endpoint come from. OpenID connect is built on top of OAuth 2. There's quite a lot in there, but it's still probably worth a look. This blog article is also very good (as are others in the same blog).
Unfortunately, I don't think Google's implementation is currently up to date with the latest spec draft so it will probably be a moving target for some time. These things have changed a lot over the past year.
I agree with your first point that you should be obtaining a new access token each time you authenticate a user, rather than refreshing an old one. You don't know who the user is until they have logged in and granted you an access token. In general, the lifespan of an access token is not linked to the user's session. Once issued, your application could theoretically use it to access resources independently of the user's presence. If you want to carry on accessing the resource beyond the token expiry time, then you need to submit the refresh token at that point to obtain a new access token. I'm afraid I don't know what the "auto-refresh" feature is for.
I believe Google's tokeninfo is analogous to the check_id endpoint of OpenID connect, but accepts either an access token or an id token, rather than just the latter. Note that the expiry times of the two may differ. You would typically be able to retrieve more detailed user data from the userinfo endpoint than from check_id, which would normally return the bare user_id.
You shouldn't need to store the id_token. It is a bit like a record of the user's authentication by the authorization server. The access token is what your application will be interested in maintaining once you have validated the user identity.
I've found several questions that are sort of similar to mine, but not 100%.
I've got a site which has normal user accounts. You have the option of using FB auth as well. The problem is often when the user visits the page (sometimes even after a few hours) even though the users account cookie is still valid, their facebook session is not.
So the user appears to be logged in, (the webpage says "Hi, [user]") but I have no facebook session, and any facebook API call will fail until they re-click "login with facebook". -- This is all despite the fact that I'm still logged in to facebook.
Now, I did a similar implementation about 11-9 months ago, and the facebook session rarely ever expired. Now it seems to happen every few hours. Oddly, other websites which use facebook auth don't seem to be suffering from this problem.
Any idea what I can do to keep the facebook session alive for as long as possible?
Thanks,
Nick
Most people combine the php-sdk with the js-sdk. This looks for auth events and will usually trigger a reload of the page signing the user back in to facebook
There's some sample code on the developer site, just above the following anchor
https://developers.facebook.com/docs/guides/web/#insights
My goal is to use Facebook Login on a website with as few api calls as possible. I don't want to use any server-sided facebook api call on sites that don't interact with facebook at all. That means I only want to use api calls for logging in and publishing things. However I don't want to use Facebooks offline_access permission flag.
Here are some thoughts:
Use own sessions for the site instead of relying on Facebook sessions. So a user stays logged in even if the Facebook session token is expired. Otherwise the user will be logged out as soon as the token is expired and needs to click login again to get a new token or Facebooks JS SDK will auto-login but this still isn't perfect because the user will see the page in "logged-out state" and it will refresh as soon as the JS SDK got a new token. No-JS users have to click the Login button again.
Cache Facebook user data in database or memcache. Use Facebook API Subscription to keep the database updated. -> No need to ask the API for changes in the user's Facebook profile.
Problem:
While using own sessions the Facebook session token might be expired when trying to publish sth. on Facebook. So you have to abort the current script and get a new token by redirecting the user to Facebook or using the JS SDK. Then continue the script. This is pain.
My thought on how to solve the problem:
Instead of publishing things on Facebook using PHP you can also do this in Javascript. If the token is expired just get a new one using JS which does not require the page to be reloaded nor the page to be redirected to Facebook. However I want to support users with disabled Javascript and then this is not possible.
In my opinion the only useful approach is to use own sessions with cached user data and keep the people logged in even if the Facebook token is expired. But redirect them to Facebook and back as soon as Facebook interaction is required. This way the user won't see the page in "logged-out state", no Javascript is required and the user will be only redirected to Facebook Login if it's really needed. For Javascript users the Facebook JS SDK will renew the token (which is then stored in a cookie) without the user noticing this as the user is still logged in (using the own session handling).
What do you think? Is there another (better?) approach to do this? My last point quite seems doable but isn't there an easier way? Thanks.
I had this exact same issue when creating an authentication system for my website. Like Elad Lachmi said, you can run FB.login on each page load - but this will cause a quick popup flash (gets very annoying).
My solution actually ended up requiring me to use offline_access. It seems that there is just no other appropriate way to keep the user logged in if they leave your site for a couple of hours.
Here's the (potential) catch:
Log the user in via Facebook without offline access
On each page, use jQuery to write an iframe to a specially formed URL which uses FB.getLoginStatus, and set it to refresh every 15 minutes
This combination should, every 15 minutes, fetch the most up-to-date user session ID from Facebook. It will cause it to be updated when it is close to expiration.
Please note that I haven't tried this, and it may be against the Facebook ToS. But it is really the only solution without using offline_access if you want to keep a user logged in for more than 2 hours without requiring them to refresh a page.