I remember all the stuff from the signed request for canvas apps: http://developers.facebook.com/docs/authentication/signed_request/
Now I'm using the JS SDK (FB.login() method), which already gives you the auth token et al. as well as a signed request. Instead of the info that a canvas app's signed request gets, I get just:
{"algorithm"=>"HMAC-SHA256", "code"=>"2.AQAdX5Zl5gY-Z_D7.3600.1322193600.1-XXXXX|HmarTBK09MSiB0o76cLgaTUd4y4", "issued_at"=>1322188281, "user_id"=>"XXXXXX"}
So what confuses me is: what's the point of the JS SDK's signed_request? I already have all the info I need from just the login reply.
when your app user comes to your https://apps.facebook.com/myapp he comes with signed_request.
Then you serve your user to your landing page. In that landing page fb jsdk loads and writes to cookies to browser.
Then when user comes to your server he comes with these cookies. So writing cookies are not your job but fb jsdk's job.
Then your server reads those cookies and process further actions.
Additional info
While surfing at github, I found
This client library is designed to support the Facebook Graph API and
the official Facebook JavaScript SDK, which is the canonical way to
implement Facebook authentication.
and
If you are using the module within a web application with the
JavaScript SDK, you can also use the module to use Facebook for login,
parsing the cookie set by the JavaScript SDK for logged in users
Taken from here.
There can be extra information provided in signed_request that isn't provided in the login response.
For example, if you need to check if a user is a fan of the page housing the app, this information is provided in signed_request. This can be injected into the page at load time by the server if the user is authenticated at that point, however if you are using an ajax authentication and signed_request were not provided in the login response, you wouldn't be able to check the fan status.
Related
Quick short background
I'm building a standalone web app using Angular JS 1.5. This web app makes usage of a API built with Laravel 5.2 (no sessions, just JWT Tokens and REST calls). Using Laravel-Socialite, I managed to make the following structure. It works nice and all, but we kind of have a overload of redirects.
The Button calls a /facebook route that invokes the Socialite magic box which leads to redirect to the Facebook Page for authorization.
After I achieved this, I noticed that a Facebook Login LOOKS a lot more of a front-end task than a back-end one. It's just about helping the user quickly sign up using Facebok available data or sign in without a password.
The Problem
Socialite makes usage of my Facebook App Secret, not to mention that it's a known environment server operation, while a Front-end we may never trust. Here is what I managed to achieve using JavaScript SDK (with AngularJS).
On a first-time access, I can get that information and sign up the user and automatically sign him in. But the problem lies on a existing user.
In this case, technically I can use the response.email information that Facebook gave me and make a request to my API to make a login without a password. But can I really do it? How do I make sure the request is being made because Facebook authorized it? After Facebook replies to my Web App, what is a secure way to tell my server that it can issue a JWT Token to that email?
Conclusion
Do I make the three-step redirection (Web App → Server API → Facebook) to sign in / authenticate a user using Facebook or is there something I'm missing here that could be the key to transferring this responsibility to the front-end (and avoiding a 3-step-redirection)?
So I'm developing my own API for my website - I'm mimicking the Facebook JS SDK in regards to how my system works. API client displays a button, popup comes up and the user can log in. Login popup issues an event to the opener window and the parent window now knows the user is logged in. That all works.
What I'm having trouble understanding is how they can verify that the refresh requests are valid. If the API client needs to send a request to the server to ask if the user is logged in and it's all in JS, then everything is transparent. The API client says, "Hi, I'm application 4jhkk2l3bnm389, is the user that's logged in on Facebook also authenticated with me? If so, can you send me a new token so I can make API calls?" and Facebook says, "Oh, you're application 4jhkk2l3bnm389? Yeah, the user is logged in and has allowed you to access their information, here's an access token."
But how does Facebook prevent an outside application that isn't the authentic application from saying, "Hey, I'M actually application 4jhkk2l3bnm389, I promise I'm not lying. Can I have an access token?"
I have no idea how they determine the difference. Obviously if it was all done through AJAX calls in modern browsers then you could just provide an Access-Control-Allow-Origin header. But if a malicious client were to use cURL then I don't think I could ever tell the difference. How does Facebook do it? A good explanation is much appreciated! Thanks!
All access tokens belongs to an app/user pair, and in order for Facebook to return such an access token to the app, these has to be verified.
The app, or client_id, is verified against the domain specified in the redirect_uri - if the page tries to use a client_id/redirect_uri pair it does not own, then it will not receive the access token as this will be passed to the valid redirect_uri (the mechanism the JS SDK uses follows the same rule).
The user, or uid, is verified using the cookie Facebook sets when you sign in.
While you can easily spoof the client_id/redirect_uri pair using curl, the same does not apply to the uid, as you would have to be in the possession of the users cookie. And if this is the case, well, then you could simply grant your own application access.
Facebook uses OAuth 2.0 for authentication. You can find details of how Facebook deals with OAuth right here: https://developers.facebook.com/docs/authentication/. There are many different ways OAuth can be used, depending on whether you're on a mobile device, a page on facebook.com itself, or, in your case, just a web page outside of facebook.com. The details of that final flow can be found here: https://developers.facebook.com/docs/authentication/client-side/.
Basically, Facebook knows what applications you have given permission to view your information. When you run one of those applications, they first make sure you are logged in to Facebook, then they request a user access token from Facebook, essentially saying, "Hey Facebook, I don't know this person, nor should I. Can I get access to their information?". And then Facebook looks internally and if it decides this particular application should have access to this user's information, it sends a user token.
That's the simple way of describing it. There are many different ways the authentication flow can happen, depending as I said earlier on what kind of device the request is happening from, whether this is a page on facebook.com, etc., essentially based on your security constraints. Best to read the Facebook authentication docs referred to earlier for the details since it can get quite tricky.
I want users to be able to register on my mobile (web based) app and login using their Facebook account. Is this possible using the JavaScript API?
The user can login using Facebook, and the userID and auth code of that user can be sent to my server to create the account, but I see a security flaw because then anyone could then log in as anyone by sending a userID and their own auth code. So can user accounts not be done with the JavaScript API and only with a server side API?
All Facebook requests are also signed with a secret key that belongs to the app you've registered to handle Facebook sign-ups on your website, so you can use that to verify it comes from Facebook and not someone else.
This is also outlined in the registration documentation
Strictly speaking, it is not possible for the Facebook SDKs to explicitly create a new user. However, when you implement a 'Login with Facebook' button (see here for JS and here for PHP), Facebook's OAuth dialog appears, which will prompt the user to log in (if they are not already) or to sign up with Facebook, thereby creating a new account, albeit not under your control.
There are few questions with same name but none of them intended to ask what I have in my mind. So we initialize FB js sdk with only app id. It's easy to know other web site's app id by looking at their facebook initialization source code. One might think that it's possible that a hacker might try to initialize FB JS SDK with other's app id and try to get their user access tokens. But facebook doesn't allow such stuff. You have to load js sdk from the same domain you specified in the site url property in Facebook Developer Apps page. So the question is how do they know that the jsonp whatever calls coming from the right client? It's not safe to that checking in client side since people can copy and modifty the javascript as they wish. So it has to be server side checking. I can only think of "referer checking" but I feel it cannot be considered a safe way.
Well, I'm not sure so this is only speculation..
First of all, when making an http request the HTTP referer header is added, and so when you load the sdk the url from which you're making the request is added as a referer.
Facebook can check on their servers where the request was originated from and compare that to what they have for the app settings.
It's possible of course to modify this header when making the request, which is why you don't get any error just by loading the sdk for an app if you're in the wrong domain.
The error will only occur when you try to interact with the sdk, for example trying to execute the FB.login method will open the auth dialog pop-up which will show the following error message:
An error occurred. Please try again later.
If you check the url of this auth dialog (which the sdk constructs) you'll notice these two query string parameters:
domain=THE_DOMAIN_OF_THE_PAGE
redirect_uri=FACEBOOK_URL which will contain origin, domain and relation=opener
What (probably) happens is that facebook checks the domain against the app settings, if it's ok it presents the user with the auth dialog, when he finished the process he is redirected to the redirect_uri.
Since the redirect_uri opens in the pop-up it can only communicate with it's opener if they are both in the same domain, a facebook domain which no one can have on his page other than pages served from facebook.
When the sdk loads it adds an iframe into the fb-root container which loads a facebook js which is loaded from the same domain as the redirect_uri, because of that the pop-up window can communicate back with the iframe and inform it with the auth response.
After the iframe got the response, the pop-up closes and the iframe informs the loaded sdk in the main page of the response.
I'm not sure which technique they use for that communication, but you can easy find more info about that by googling "cross domain iframe communication".
That's how I see it, but I can't be sure.
You can check the code for the js sdk # github if you want to really know what's going on.
According to the Facebook API documentation, most of the work is handled through javascript.
That means that all the processing is done, and then the front end checks if the user is connected to Facebook/authorized. right?
My question is:
Suppose a user goes to my site for the first time ever.
He clicks on "facebook connect". The javascript verifies him as authentic, and it "redirects" to another page on my server. From then on, how do I know that the user is actually authenticated to my website, since everything is done on frontend?
I think this is correct, but aren't there some security issues..:
-After user clicks Login, Facebook redirects to a page on my site. AND they also create a cookie with a specific "Facebook ID" that is retrieved only from this user. My backened will "read" the cookie and grab that ID...and then associate it to my userID.
If that is correct...then it doesn't make sense. What if people steal other people's "facebook ID" and then forge the cookie? And then my backend sees the cookie and thinks it's the real user...?
Am I confused? If I am confused, please help me re-organize and tell me how it's like.
Facebook Connect uses a clever (or insane, depending on your point of view) hack to achieve cross-site communication between your site and Facebook's authentication system from within the browser.
The way it works is as follows:
Your site includes a very simple static HTML file, known as the cross-domain communications channel. This file is called xd_receiver.htm in the FB docs, but it can be named anything you like.
Your site's login page includes a reference to the Javascript library hosted on Facebook's server.
When a user logs in via the "Connect" button, it calls a function in Facebook's JS API which pops up a login dialog. This login box has an invisible iframe in which the cross-domain communications file is loaded.
The user fills out the form and submits it, posting the form to Facebook.
Facebook checks the login. If it's successful, it communicates this to your site. Here's where that cross-domain stuff comes in:
Because of cross-domain security policies, Facebook's login window can not inspect the DOM tree for documents hosted on your server. But the login window can update the src element of any iframe within it, and this is used to communicate with the cross-domain communications file hosted on your page.
When the cross-domain communications file receives a communication indicating that the login was successful, it uses Javascript to set some cookies containing the user's ID and session. Since this file lives on your server, those cookies have your domain and your backend can receive them.
Any further communication in Facebook's direction can be accomplished by inserting another nested iframe in the other iframe -- this second-level iframe lives on Facebook's server instead of yours.
The cookies are secure (in theory) because the data is signed with the secret key that Facebook generated for you when you signed up for the developer program. The JS library uses your public key (the "API key") to validate the cookies.
Theoretically, Facebook's Javascript library handles this all automatically once you've set everything up. In practice, I've found it doesn't always work exactly smoothly.
For a more detailed explanation of the mechanics of cross-domain communication using iframes, see this article from MSDN.
Please someone correct me if I'm wrong - as I am also trying to figure all this stuff out myself. My understanding with the security of the cookies is that there is also a cookie which is a special signature cookie. This cookie is created by combining the data of the other cookies, adding your application secret that only you and FB know, and the result MD5-Hashed. You can then test this hash server-side, which could not easily be duplicated by a hacker, to make sure the data can be trusted as coming from FB.
A more charming explaination can be found here - scroll about halfway down the page.
Same issues here, and I think Scott is closer to the solution.
Also Im using "http://developers.facebook.com/docs/?u=facebook.jslib-alpha.FB.init" there open source js framework. So things are a little different.
For me, via the opensource js framework, facebook provides and sets a session on my site with a signature. So what I am thinking is to recreate that signature on my side. - if they both match then the user is who he says he is.
So basically if a user wanted to save something to my database, grab the session signature set up by facebook and recreate that signature with php and validate it against the one facebook gave me?
if($_SESSION['facebookSignature'] == reGeneratedSignature){
// save to database
}else{
// go away I don't trust you
}
But how do you regenerate that signature? preferably without making more calls to Facebook?