This bit of the Google Data APIs Protocol spec intrigues me:
- A web-based client, such as a third-party front end to a GData service, should use a Google-specific authentication system called Proxy Authentication for Web Applications. This system is not yet available for use.
Beyond the fact that they said it’d be ready in late April and it’s already getting late by my watch, I’m curious aobut how they’re accomplishing this. This must be absolutely secure, because I have a feeling they’re going to be providing access to some pretty sensitive data using this, such as GMail data.
With desktop apps, Google is giving the application a cookie that they can use to authenticate with. Obviously this doesn’t in browsers because cookies aren’t secure. So how are they planning to authenticate Web apps?
I’m sure Google wants and NEEDS this authentication mechanism to be absolutely secure, so they’re probably not using any of the existing HTTP authentication mechanisms (Joe Gregario has a hilarious description of problems with the current mechanisms written up as a Monty Python sketch). Basically, the problems are born out of issues with the implementation of HTTP authentication on either the server (with Apache) or client (with IE) side. None of the methods work across the board.
Is Google using a reverse proxy to hide their internal system from the unsecured Web, and forcing users to authenticate with that proxy by sending a 407 error (Proxy Authentication Required)? No matter which browser or server the application is running on it will be able to connect. It will marry together the different authentication mechanisms so that any application will be able to authenticate using a Google login regardless of what methods it supports. This is a pretty cool idea. In other words, take your pick, we support ‘em all.
If this is true, it would actually support both browsers and servers as endpoints for the GData service. I’ll be keeping an eye on this to see what they do, should be interesting. It looks like it could be the only way to do true HTTP authentication right now with the quagmire that’s resulted from the fragmented implementations of standards.
