Getting Started with Account Authorization

The Google Account APIs allow third-party applications to get limited access to a user's Google accounts for certain types of activities. For example, you might want to enable your users to view and work with their Google data in your application, create mashups of data from multiple sources, or give your users the ability to add data to their Google service from your application. Alternatively, you might want to let users enter your application with their Google log-in.

The Google Authorization Service manages authentication, authorization, and access control to user accounts, subject to approval from the account holder. Google offers several account authorization APIs to accommodate different types of access. If you're a third-party application developer who wants to implement some type of access to a Google account, use this page to help determine which type of Account API is appropriate for what you need.

Step 1: What do you want to do?

Let users log into my application using their Google Account.

With Google's Federated Login API, web applications can hand off user authentication tasks to Google. This feature frees you up from having to manage log-in information and security measures, and also avoids forcing your users to set up yet another login account. When using Federated Login, your application does not handle any login information; on a successful login event, Google returns a persistent user identifier, which your application can use to recognize individual users, handle sessions, store user-specific data, etc. Federated Login is based on the open-source OpenID 2.0 protocol; you can use the same interface to accept logins from any OpenID provider. Federated Login is designed for web applications only. It is now available for users with Google Apps (hosted) accounts.

For help implementing a login solution, see Federated Login for Google Account Users.

Get authorized access to users' Google data.

Many Google services allow third-party access to user-generated data, such as Calendar or feed data, so long as access is granted by the user. This feature allows users to share and exchange data between their Google applications and third-party applications for a variety of purposes. Google supports several options for getting authorized access to a user's Google data, offering access to both web applications and installed applications.

For help determining which authorization API is right for you, continue on to Step 2.

Let users log in with a Google Account AND get access to their Google data.

If you want to do both login authentication AND get authorization to access user data, you can implement a hybrid version of Google Federated Login combined with OAuth. The primary advantage of using the hybrid protocol is that it streamlines the user's authentication/authorization experience into a single step. OAuth requires additional security for access authorization over other authorization APIs supported by Google; for example, web applications using OAuth must register with Google. If you need to use a different authorization solution, such as one with more relaxed security requirements, you'll need to implement authentication and authorization as separate processes; in that scenario, users would need to grant access on two separate Google request pages.

For help implementing the hybrid solution, see Implementing OAuth with Federated Login on the Federated Login page.

Step 2: What type of application are you working with?

I'm developing a web-based application.

Web applications that need authorized access to services protected by a user's Google or Google Apps (hosted) account can choose between either the Google-proprietary AuthSub API, and Google's implementation of the open standard OAuth API. Many--but not all--Google services support both APIs; check with the service you want to access to verify which APIs it supports.

Factors to keep in mind when choosing between OAuth and AuthSub authorization:

• Universality: If you're designing an application that needs authorized access to other service providers as well as Google (assuming those providers support OAuth), consider using OAuth; because it's based on an open standard and can be used with both Google and non-Google services.
• Security: Google offers several levels of security. Applications that are registered with Google and digitally sign all requests using a securitycertificate are recognized by Google and offer a higher level of security to users. Both AuthSub and OAuth allow for registered and unregistered access.

For help implementing authentication for a web-based application, see either of these pages:

• OAuth for Web Apps
• AuthSub for Web Apps

I'm developing an installed application.

An "installed application" is defined here as installed on a machine such as a desktop computer or a mobile device. As with web applications, third-party installed applications can benefit from exchanging data with users' Google services. Installed application developers can use either a Google-proprietary ClientLogin API, or Google's implementation of the OAuth API for installed applications.

Factors to keep in mind when choosing between OAuth and ClientLogin authorization:

• Universality: If you're designing an application that needs authorized access to other service providers as well as Google (assuming those providers support OAuth), consider using OAuth to avoid having to set up duplicate authorization mechanisms.
• Security: Neither ClientLogin nor OAuth offer the high level of security of OAuth for web applications (where applications register with Google and can be verified) but each provide different strengths.
  • With OAuth, the Google Access Request page displayed to the user contains a warning message indicating that the referring application cannot be verified (see example). No such message is displayed with ClientLogin.
  • With ClientLogin, the user must provide their username and password to the third-party application, which is then transmitted in the request to Google. In contrast, with OAuth no login details are acquired nor communicated by the third-party application.
• Login process: Before the authorization process can proceed, users must first log into their Google account. The user experience is quite different between ClientLogin and OAuth solutions. ClientLogin handles login behind the scenes, requiring user intervention only to resolve a CAPTCHA challenge when one is triggered. However, ClientLogin provides only limited flexibility with login; for example, users must have an existing Google account and provide accurate login in information to the third-party application. By contrast, OAuth requires users to log in using the familiar Google login box. At the same time, it offers greater flexibility in the login process: it allows users to select from multiple Google accounts (if they are logged into more than one), supports SAML-enabled hosted domains, handles edge cases such as login errors and suspect attempts in a familiar Google experience, and lets users create a new account if they don't already have one.

For help implementing authentication for installed applications, see either of these pages:

• OAuth for Installed Applications
• ClientLogin for Installed Applications

Feature comparison