I have the javascript side working instantly. I have a picture of myself and "Mark Lester uses Gee GTFS Editor" in my title bar. Nice. But I just don't get how I now get my service, which of course is a couple of Java programs returning JSON, to know that it really is mark.lester.5454021 that's signed on, and not someone hacking the javascript etc. How I assumed this would work is that the user would have a key (I've fbsr_<my_app_id> set as a cookie and I added the access token as another cookie value). This key (presumably one of the above), and their name possibly, is passed to my service, which in turn then makes a direct call to Facebook, perhaps using the secret, to validate that this is a valid key, i.e. yup, we just signed him in and that's the key we gave him, or nope, that doesnt add up. But it doesnt work like that does it. I can imagine that the Identity Provider hands back some magic bundle encoded using the secret, so the service provider doesnt have to make a direct back channel call bacl tp the IdP, it can just decrypt and validate, but that seems to be even more off beam. Within reason, I dont even mind paying for the privilege, but I cant even work out how you do that I tried oneall.com but I still dont get how the SP is supposed to be sure this is who they say they are. And, at least in the short term, I dont mind telling my punters, who of course are all beta testers, "you got to single sign on using this single platform, e.g facebook).
http://blog.mixu.net/2011/01/03/implementing-facebook-login-part-2/ really really good explanation of stuff. So yes, you just need the app secret and the fbsr_<app_id> cookie to go, no direct back channel to facebook