OpenID Federated Login Service for Google Apps

Google Apps offers an OpenID API that allows end users to securely sign in to third party web sites using their Google Apps user account. The OpenID standard frees users from having to set up separate login accounts for different web sites--and conversely, frees web site developers from the task of managing login information and security measures. OpenID achieves this goal by providing a framework in which users can establish an account with an OpenID provider, such as a Google Apps hosted domain, and use that account to sign into any web site that accepts OpenIDs.

Google Apps API supports the OpenID 2.0 Directed Identity protocol, allowing any hosted domain to provide authentication support as an OpenID provider. On request from a third-party site, Google authenticates users who are signing in with an existing Google Apps account, and returns to the third-party site an identifier that the site can use to recognize the user. This identifier is consistent, enabling the third-party site to recognize the user across multiple sessions. The OpenID API also supports the following extensions:

OpenID Attribute Exchange 1.0 allows web developers to access, with the user's approval, certain user information stored with Google, incluing user name, email address, country and preferred language.

OpenID+OAuth Hybrid protocol lets web developers combine an OpenID request with an OAuth authentication request. This extension is useful for web developers who use both OpenID and OAuth, particularly in that it simplifies the process for users by requesting their approval once instead of twice.

For the Enterprise and the organization, the Google Apps OpenID API enables a Universal Single Sign-on service. A single Google Apps login can provide secure access to Salesforce.com, additional Saas and on-demand solutions, B2B partners, internal applications and consumer web sites. See our blog post for more details and examples.

For more information on the OpenID framework, refer to the following specifications:

• OpenID
• OpenID attribute exchange
• Step2 open-source project including complete Relying Party example code

See also the Federated Login for Google Account Users and Google Group on Federated Login for discussion on using Google's OpenID API.

Note: The Federated Login Service is disabled by default for Google Apps Premier and Education Editions. The domain admin can enable it from the Control Panel at http://www.google.com/a/cpanel/<your-domain>/SetupIdp.

Understanding OpenID-based Federated Login for Google Apps

This section provides a high-level overview of how OpenID authentication works.

Interaction Sequence

OpenID login authentication for web applications involves a sequence of interactions between thre 3rd party web application, the Google Apps hosted domain, Google domain, Google's login authentication service, and the end user. The diagram and sequence below describe the process as recommended by Google. For simplicity, the diagram covers the flow in which discovery is done on the Google domain. See the Google Apps Relying Party Discovery Documentation (experimental) for the complete flow and examples.

Note: It is highly recommended that domain admins post a host-meta filedocument as described in the Discovery Documentation.

This image illustrates the following steps.

1. The web application asks the end user to log in by offering a set of log-in options, including Google Apps accounts.
2. The user selects to sign in using a Google Apps account.
3. The web application performs discovery as defined in the documentation to find location of the XRDS document. 
4. Google returns an XRDS document, which contains the Google Apps (hosted) domain endpoint address.
5. The web application sends a login authentication request (optionally with OAuth parameters) to the provided endpoint address.
6. This action redirects the user to a Google Apps account Federated Login page.
7. The user signs into their Google Apps account. Google Apps then displays a confirmation page and asks the user to confirm or reject a set of authentication requests by the web application. If the web application is using OpenID+OAuth, the user is also asked to approve access to a specific set of Google Apps services.

   Note: In some circumstances the login step or the approval step (or both) may be skipped.

8. If the user approves the authentication, Google returns the user to the web application, and supplies a persistent, opaque identifier that the application can use to recognize the user. For OpenID+OAuth, an authorized request token is also returned.
9. The web application uses the Google-supplied identifier to recognize the user and allow access to application features and data. For OpenID+OAuth, the web application uses the request token to continue the OAuth sequence (at step 7) and gain access to the user's Google Apps services.

Relying Parties - Designing a Scalable Login User Interface

You can design your federated login page in any way that fits your site; the page simply needs to (1) solicit information from the user about how they want to sign in, and (2) trigger the sign-in process. The traditional OpenID specification called for a login box or other text entry field that required the user to supply some kind of identifier. For Google Apps directed identity approach, we recommend any of the following options:

• Replace the login box with a button or link that says "Sign in using a Google Apps Account". Relying parties that support multiple identity providers will want to provide a series of links or buttons.
• Use a login box to request a user's e-mail address. The web application can then check that the email domain is for an identity provider it trusts, such as Google Apps hosted domain, and then start the discovery process as if the user had supplied that identity provider
• Display an OpenID branded box where users can enter the URL of the identity provider or select one from a list.

We recommend keeping the interface as simple as possible. Visit the User Experience summary for Federated Login Google Sites page, where you can find links to demos, mocks and usability research data.