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;

-----BEGIN CERTIFICATE-----
MIICSjCCAbOgAwIBAgIJAKy5FQe8xe

W/MA0GCSqGSIb3DQEBBQUAMCMxITAfBgNV
BAMTGGZyaWVuZGNvbm5lY3QuZ29vZ2xlLmNvbTAeFw0wODEyMTkxOTQ3NDlaFw0w
OTEyMTkxOTQ3NDlaMCMxITAfBgNVBAMTGGZyaWVuZGNvbm5lY3QuZ29vZ2xlLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvvHLRIP0tKwFGExqfIOf25Ad
2WHq/Oz4CuuspA75pvXg5+w9E4P5oMNmGNENO7LAA+xSrXLND+FdDg4STH/5FW0Y
ycPhw7LvqsefQwnntn1oHGTYffWRPbovHZBDcCBJZ2cgzXnmsXG9D7rO06fikTaa
6aSw1mVt7sFvwZDegEkCAwEAAaOBhTCBgjAdBgNVHQ4EFgQUITh3OCFLiiyTPEsq
LKmuALCpfXwwUwYDVR0jBEwwSoAUITh3OCFLiiyTPEsqLKmuALCpfXyhJ6QlMCMx
ITAfBgNVBAMTGGZyaWVuZGNvbm5lY3QuZ29vZ2xlLmNvbYIJAKy5FQe8xeW/MAwG
A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAvnVl15uganMvEwABVxRwMAys
ICPuzrxvdgAHXDl1/FCv68CEbTatHYPHBTLiY66DL8HICWwFuIx4j0DTuj6IWHRG
iP2BFvtcRvogURixojA+JXsvIjafoShzqAioDptVUx1aIHM+af3B5zE6+wDVmRUz
1WeG3BvhoqPq1pUdWig=
-----END CERTIFICATE-----

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.

Until

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!!!


Cheers,
PS

Continue Reading...

Google Friend Connect finally support signed request

Why is that a big deal?

Here's the short answer; Now you can get the viewer id of a user loading your page and send it back to your server in a trusted way.

Before (up to two weeks ago, when I last tried it) it was only possible to send back info from the web page in an untrusted way.

What I mean by that is that you could load a custom opensocial gadget, which got the viewer id using the opensocial api, and then proceeded to use the opensocial makeRequest() call to route that information back to an url on your server. However, since this information orgiginated in the browser, potentially someone might somehow get a malign script to run on your page (from an ad, perhaps) and make up any old id, to then send back to your server.

In the opensocial specification, there is different modes of makeRequest, of which one is to make a signed request. To describe a signed request, I've drawn a small diagram above. Let's walk through it, and return to the signed request in a little while.

Let's say that you have copied in some Google Friend Connect gadgets on one of your pages, by registering your site with GFC, noting your sites code, and so on, the first thing that happens is that a person going to you site loads your page (1). In your page lies the gfc gadget references, which load the gadgets themselves from the GFC proxy servers (I call them proxies since much of what they do is route information back and forth third parties) (2). If this is the first time the users has been to the site and/or the user have not 'joined' the site on a GC sense, he/she may now proceed to do so (still (2)).

Now you have written your own, custom opensocial gadget, which is also loaded into the page in (2). It probably resides on your server, but could actually be loaded from any server on the internet. That gadget does the following;

a) Get the id of the viewer
b) tell the gfc/opensocial JavaScript api that is loaded to post the data to an url on your server. Two weeks ago, this could only be done without authentication.

This will send the data (viewer id) first to the gfc proxies(3), which will then route it forward to your server (4).
On your server is a special script that parses the post data out from the HTTP request (5).

The only thing that has changed now is that the makeRequest call can use the authentication mode gadgets.io.AuthorizationType.SIGNED, which will result in a 'stamp' made by the gfc proxies as the message passes through them. This is what it looks like in a small PHP script I wrote to collect the incoming signed info;


2009-02-22 12:41:36>---------------------> id=82146293318299142645, nick=psvensson
2009-02-22 12:41:36> post param -- the_user_id -> 32146007816295742145
2009-02-22 12:41:36> post param -- the_user_nickname -> psvensson
2009-02-22 12:41:36> get param -- opensocial_owner_id -> 03600513378691222179
2009-02-22 12:41:36> get param -- opensocial_viewer_id -> 78096296444182405045
2009-02-22 12:41:36> get param -- opensocial_app_id -> 09127246177732455082
2009-02-22 12:41:36> get param -- opensocial_app_url -> http://xxxyyyzzz.com/osaccess.xml
2009-02-22 12:41:36> get param -- xoauth_signature_publickey -> pub.1008283802.-8019269915578004945822.cer
2009-02-22 12:41:36> get param -- oauth_version -> 1.0
2009-02-22 12:41:36> get param -- oauth_timestamp -> 981102302897
2009-02-22 12:41:36> get param -- oauth_consumer_key -> friendconnect.google.com
2009-02-22 12:41:36> get param -- oauth_signature_method -> RSA-SHA1
2009-02-22 12:41:36> get param -- oauth_nonce -> 01831428822001149500
2009-02-22 12:41:36> get param -- oauth_signature -> MviLJcsxuU2tN9hQTkMEqZrEaC7ZUX31Cz7HH17I00vT2q8NJWH28OzvDab1Cl,01YtetX+Yln/IkuTj+I11SzFwZu5aXQda5D9HBeq+zjdxwWfuLGo62AaMjm5lvJGwWrMW6q+vm33MVOFWecxuXzSPmDfsCE9Tyf+b3M=

Numbers and other stuff are messed with a bit, due to posting :) But the thing is that two weeks ago, only the two POST lines were getting though, and any signed request returned and error in th browser.

This is the dawn of maybe not a new era, but a new eralischimo. Now you can use trusted user ids without having to manage the users, changing password, creating capthcas (and keeping up with the bots), listing friends and manage those connections, et.c. Now you just slam a gadget on the page, and get an id back you can trust. Not half bad eh?

Cheers,
PS

[UPDATE]

OK, this is a bit silly. There is more to this than just using signed makeRequests :) The reason I forgot this, is that the magic sauce was something I added in desperation some time ago when I tried to make signed requests work; I added a certificate to my domain using google accounts;

https://www.google.com/accounts/ManageDomains

Where you can upload a x.509 certificate that you can associate with your domain. The process is explained in more detail here;

http://code.google.com/apis/accounts/docs/RegistrationForWebAppsAuto.html

Including how to generate x.509 certs from scratch on Windows and Linux (Maybe mac as well).

Continue Reading...