What is flow of getting access_token on server-side? about facebook-node-sdk HOT 1 CLOSED

facebook-node-sdk can only be used to get the access_token using the server side flow. We don't support extracting session id from cookies. As of now we don't hav any plans to support it soon nor in the future. You can find the reasons in this blog post https://developers.facebook.com/blog/post/624/ by reading the article as well as comments from Facebook employees.

Here is for the reference an extract from the blog post:

"Cookies used by the SDKs
Our JavaScript and PHP SDKs support a common cookie format that allows you to access Facebook Platform from both client and server side code in a seamless fashion. Previously, we documented this cookie format. This resulted in many apps and SDKs taking a dependency on it. We would like to consider this cookie format to be an implementation detail so that we can make changes for security or other reasons, and advise apps not to take a direct dependency on the format. Rather than attempting to parse our cookies, we recommend that you use one of the above supported SDKs or use OAuth endpoints to directly authenticate and authorize users. Our Authentication Guide highlights how to perform authentication and authorization directly."

The comments:

Jasper Rosenberg · Williams
How am I supposed to make server side open graph Java calls that require a user access token if I can't rely on parsing the cookie in Java code?
Reply · 4 · Like · Follow Post · December 30, 2011 at 9:23pm

Douglas Purdy · Subscribe · Top Commenter · Stanford · 1,012 subscribers
You have a couple options:

1. Make the call on the client side using the FB.api method the JS SDK.
2. Get the access token from the JS SDK and pass it to the server yourself (FB.getAccessToken). Make sure you are doing that over a secure link.
3. Just do the auth on the server, rather than using the JS SDK. It is hyper-simple.

The last thing you want to be doing is parsing an internal data structure from us that we are have needed to change before and will need to change again.
Reply · 3 · Like · December 30, 2011 at 10:29pm

Jasper Rosenberg · Williams
I suppose I can just use FB.getAccessToken on document ready and compare it's value's checksum to a checksum of the access token I currently have saved for the user, and if they differ, make a secure ajax call to update it. That wouldn't be too bad, and would allow me to avoid auth redirects for posts due to expired tokens most of the time.
Reply · 1 · Like · December 30, 2011 at 11:16pm

Jeff Schnitzer · Subscribe · Top Commenter · Founder at Stealthy Startup
This gives us the access token but doesn't give us a secure way of getting the facebookid of the caller without making another call to facebook from the server and then managing (and expiring) a signed cookie ourselves. Facebook should provide a signed version of the fbid of the caller - which is exactly what is in the cookie, and exactly what the PHP SDK reads.
Reply · 2 · Like · December 31, 2011 at 3:10pm

Douglas Purdy · Subscribe · Top Commenter · Stanford · 1,012 subscribers
Jeff Schnitzer The uid is available on the client. Pass them both to the server. BTW: if you are building a canvas app, we pass all this info to you in the signed request.
Reply · Like · December 31, 2011 at 6:17pm

Jasper Rosenberg · Williams
Douglas Purdy But canvas apps are not long for this world, no?
Reply · Like · December 31, 2011 at 9:14pm

Douglas Purdy · Subscribe · Top Commenter · Stanford · 1,012 subscribers
Jasper Rosenberg: what gives you that idea? Most of the biggest apps on Facebook are canvas and we are seeing a slew of new ones since f8. Building a canvas app is the easy way to get new users to share with your app and their friends because they are used to doing this on Facebook already.
Reply · Like · January 1 at 1:32am

Jeff Schnitzer · Subscribe · Top Commenter · Founder at Stealthy Startup
Douglas Purdy: Our servers cannot trust an id submitted by the client, otherwise anyone with a cookie editor could masquerade as any other user. We need the id to be digitally signed by facebook, ie exactly what is present in the fbsr cookie.
Reply · Like · January 1 at 5:34pm

Douglas Purdy · Subscribe · Top Commenter · Stanford · 1,012 subscribers
Jeff Schnitzer there are N number of ways to ensure that the uid is from your own client, including signing the request/cookie yourself. Further, you can do all this on your own server. You don't need our cookie.
Reply · Like · January 1 at 10:59pm

Jeff Schnitzer · Subscribe · Top Commenter · Founder at Stealthy Startup
Douglas Purdy: All of those ways require the client to 1) send the access token to the server, 2) the server to make a graph call to /me to get the userid, and 3) to sign and store the id in the cookie. This is a ridiculous amount of work considering that a signed identity is already present in the fbsr cookie and the PHP SDK already reads it. You can't change this format without forcing everyone to upgrade their PHP SDKs, so you might as well document it and let non-PHP SDKs in on the fun.
Reply · Like · January 2 at 12:33am

Douglas Purdy · Subscribe · Top Commenter · Stanford · 1,012 subscribers
Jeff Schnitzer

just so everyone reading this thread is clear:

1. if you are using a canvas app, you get all this info from the signed_request.
2. you can also just do server-side auth yourself, which is what many devs do.
3. you are drilling into a scenario where you want to use the JS SDK for auth and then roll your own SDK and read our cookie format.

i actually don't think it is too much work (if you have a way of trusting the access token from the client, you don't need to make the /me call) and best real web apps have to set their own cookies for any # of scenarios.

as for the changing the cookie format, you are correct, but we are completely control both of those SDKs and if needed we can push out this change very quickly. apps would need to react, but the solution is self-contained (update your PHP SDK). it would be impactful, but not as impactful if we documented the format and who knows is depending on it.
Reply · Like · January 2 at 12:48am

Jeff Schnitzer · Subscribe · Top Commenter · Founder at Stealthy Startup
Douglas Purdy

The developers impacted by this are everyone who wants to use the Javascript SDK with a non-PHP server. You also seem to misunderstand the security considerations of web applications - servers cannot trust anything provided by the client. Unless the access token itself contains the userid with a digital signature that can be verified, the only way to safely obtain the identity of the caller is to make a graph call to /me.

Is this too much work? It's more work (and latency) than required by the PHP SDK. Let me tell you what actually happens in this situation: Instead of doing all that extra work and making those extra calls, developers look at the PHP code and decipher the cookie. And then when you change the cookie without warning or documentation, we blame you for creating a poorly documented platform. And the reputation of Facebook's developer platform continues to degrade.
Reply · 1 · Like · January 2 at 1:14am

Douglas Purdy · Subscribe · Top Commenter · Stanford · 1,012 subscribers
Jeff Schnitzer

almost everyone I know that uses a non-PHP server does auth on the server.

it is much simpler than using the javascript sdk, particularly if you are making server-side calls.

so i think that everyone is much smaller than you expect.

i understand the security implications of web apps, so i think we are miscommunicating here.

we are being very clear about our expectations around this cookie, so i hope either you or anyone takes a dependency.

as for our reputation, that is for others to decide, but we are doing everything we can to:

1. be clear about what we support and don't.
2. decrease the surface area of our platform to the level that we can actually support and react to quickly when there are issues.
   Reply · Like · January 2 at 2:43am

Jeff Schnitzer · Subscribe · Top Commenter · Founder at Stealthy Startup
Douglas Purdy

Simpler? What could be simpler than including the FB js and putting a fb:login-button on your page? Redirecting my users off of my website is an inferior user experience, and figuring out how to get oauth to pop up in a dialog is not simple at all.

I'm honestly struggling to find public example of a site using straight-up oauth redirects for facebook login. Ticketfly, Quora, Groupon, Foursquare, and Digg all use the JS SDK.

The bottom line is that you're saying the Javascript SDK only communicates the userid to the server when you use the FB PHP SDK, and all other platforms must resort to hacky workarounds (or use the inferior user experience of server-side auth). I don't expect Facebook to develop SDKs for all the platforms of the world, but I'm really disappointed when you actively conspire against them.
Reply · 1 · Like · January 2 at 3:58am

from facebook-node-sdk.