'

Google releases answer to Passport

Google just released the Account Authentication Proxy for Web-Based Applications [Update: Google has removed the page this link points to] -- which looks a lot like Passport.  According to the website, this proxy lets web-based applications create services protected by a Google Account by enabling a web application to get an authentication token without ever handling the user's account login information.

Google just released the Account Authentication Proxy for Web-Based Applications [Update: Google has removed the page this link points to] -- which looks a lot like Passport.  According to the website, this proxy lets web-based applications create services protected by a Google Account by enabling a web application to get an authentication token without ever handling the user's account login information.  The user must log into their account using a Google supplied login page and grant limited access to the web application.

Web applications, if granted, can access certain information associated with that users Google account -- for example Google Calendar events.  Users explicitly have to give websites access to their services before any of their data will be shared.

googlesecureaccess.jpg

 

An example of how a website can consume a users data is explained in the documentation:

Example Scenario

Users of Google Calendar manage their schedules, add, update, or delete events, and share calendar information. In this scenario, you have a web application that communicates with the Google Calendar service. You want your application to display Google Calendar data and manipulate that data on behalf of your users.

To do this, your application needs to get access to your user's Calendar account. Before accessing the account, the application must request authorization from Google. It does so by calling the Google Authentication URL and supplying some required information, such as the name of the service to be accessed. If Google accepts the request, a Google page is displayed that prompts the user to log in and either consent or refuse to provide access to their Google account. If they consent, Google redirects the user back to your web application and supplies an authentication token for the requested service. The web application can then make requests directly to the Google service, referencing the token in each request.

If  a website wants access to more than one service associated with a Google user (like Google Calendar, GMail, etc), the website must request separate tokens for each service.  The level of access granted is dependant on the Google service in question.  Some services may limit access to certain types of data.

By default, applications using this service are not trusted -- and so when a user attempts to log in, they are given a warning message.  By registering, websites will be recognized as "trusted" by Google and therefore will not display the warning.  Soon Google will also release a way for registered websites to display their logo on the page as well.