Tuesday, March 10, 2009

Google Friend Connect Public Key finally released :)

Yes! After months of general agonizing and a feeling that everything I knew about security *might* be wrong, Google releases the public key for the certificate that signs the signed requests coming from custom GFC gadgets back to your server.

Arne Rooman-Kurrik (at Google) posted the certificate to the OpenSocial mailing list yesterday, and it looks like this;


It was later verified to work by a guy called videomap (should work at Google).

For old readers of my blog the magnitude of this event is simple to understand, but just to be sure, it goes like this;

1) You think that GFC is kind of cool. You put a gadget (or several) on the pages of your site, Google manages login, authentication, friend management et.c and people can chat , rate and have fun on your pages.
2) You realize that allthoug people are having fun there is zero (0) interactivity between the GFC gadgets and your site, and/or
3) You would really like to know the unique user id of the GFC loggged in user that sees you page right now.

So, you..

4) Learn how to create a custom GFC gadget (Exactly like creating a custom OpenSocial gadgets. Just grab one of the smallest sample code files, and you're done. Well, you have to get the 'wrappin' HTML for it from the GFC admin console for your site. Whatever).
5) You put the gadget on your ite in a nice, shiny directory
6) You enter the wrapping code in your page that loads you custom gadget *through* Google's GFC servers.
7) You browse through the OpenSocial 8.x AP docs and realize that you need to do a makeRequest() call back to an url of your server, getting the usr id (and picture) is dead simple, so you have that already in the other hand.
8) Yay, Your custom gadget actually send back the info! Great.

But then you realize...

9) Anythion on your page could actually have sent back that info. A malign ad might inject some script which runs and just send back 0000 or something. Translation: You can't trust informatiuon sent from the client.
10) You find a great option to makeRequest in the OpenSocial API called SIGNED requests. This will make the container (the GFC server in this case) sign the data you send. But also add signed and correct user ids for the viewer and owner of the current data. Yay!

It doesn't work. Until..

11) It suddenly does, a couple of weeks ago GFC decides to activate SIGNED requests. Wild joy. Everything seems ok.


12) You realize you don't have the public key the GFC uses, so you can't actually verify that some *other* server on the internet tries to look like it is a GFC server and feed you false data. Eugh.

But then

13) They did publish the public key (Above), so now the circle is finally closed. We can now use GFC as a universal login mechanism, get a unique user id back to our server,a nd connect that to any data we choose.

Thanks Google!!!



Cory said...


Carl-Johan Sveningsson said...

This is all really interesting, have you by the way seen Jonas Lejon's (in Swedish) posts on the topic?


Anyway, I've worked with sort of security, PKI and timestamping, and it's so frustrating how even major players don't understand what they're doing. I'm amazed by how there isn't GFC or FBC support in major software or hosting services, so when I recently wanted to create a forum, I was more or less forced to Google Groups

Cheers anyway, it's good to see people adopt this sort of sane things

Peter Svensson said...

@Carl-Johan Svenningsson: Thanks. And also for the link. I follow Jonas on twitter but it hadn't occured to me to find his blog :o).

'Decoupled' widgets with reliable authentication is the next big thing. I have not had time to blog about the recent developments in GFC, but since exposing a simple server-based functionality to authenticate users, and at the same time expose compartmentalized functionality of your site or parts of it (as OS/GFC/Web Element), the cost of web development has dropped like a stone.

What we need now is IDE integration of some sort... Hmmm.....