Google API

Account Authentication API

There are three ways to use Google's Account Authentication API.

  1. Authentication for Installed Applications - This model is designed to support applications that a user installs locally.  Authentication happens as follows:
    1. The application prompts the user for his/her Google username and password.  Because the user is giving the application his/her password, he/she must be careful to trust the application.
    2. The application sends the name and password to Google for authentication.
    3. Google replies with a token that your application may use in any future requests to use the user's Google services (e.g., Documents, Calendar).
  2. Authentication for Web Applications - This model is designed for web applications and does not require the user to provide a username/password to the application itself.   There are two libraries that provide this capability: OAuth and AuthSub.  AuthSub was developed before the OAuth standard was released.  Generally, OAuth is the move universally compatible choice, however it requires your application to be registered with Google.  AuthSub can be used without registration of the application.  Authentication happens as follows:
    1. The user visits your web page and is redirected (by your server) to Google's login page. As part of the URL to which the user is redirected, you include a parameter indicating where Google should redirect the user once authentication is complete.
    2. The user gives his/her login information directly to Google, and tells Google whether or not to allow your site to access his/her Google services.
    3. If the user is authenticated and grants access to your site, the user is redirected back to the URL provided in step 1.  Google tacks a parameter onto the URL that provides a single-use token to your application.
    4. Your application sends the single-use token back to Google and requests a session token.
    5. Google replies with a session token that is used in subsequent requests for a user's data.
  3. Federated Login - The previous two approaches are designed to allow a third-party application to access a user's Google data.  The federated login approach, on the other hand, is designed to allow users to use the same username/password to sign in to multiple different services.  This can be done using the other approaches, but it is not the first-order goal.  Federated Login can also be used in conjunction with OAuth to allow federated login as well as access to Google data.  Federated Login uses the OpenID standard, and the approach is very similar to the authentication for web applications.

Google Documents List Data API

The Google Documents List Data API allows third-party applications to view and modify a user's Google Documents data.  

The Developer's Guide and the Reference Guide describe the REST-based APIs used to access the service.  As an example, to retrieve a list of a user's documents, you simply send a GET request to the following URI: http://docs.google.com/feeds/documents/private/full

In order to identify and authenticate the current user, the request must specify the token retrieve during authorization in the Authorization header.  If using the RESTlet Client, this is accomplished by using the ChallengeResponse.

Client Libraries

There is also a Java client library that provides a Java API for accessing the Authentication and Data services.  Essentially, the library is a wrapper that translates your Java method calls into the REST requests described above. 


Comments