Thursday, May 14, 2009

Google OpenID API - taking the next steps

Six months ago, we announced our first step in supporting single sign-on using OpenID. Well, we wanted to share with you what we have been working on since. As a strong supporter of open standards such as OpenID, Google's top priority in this area has been to join the OpenID community in its efforts to increase the adoption of the protocol by both Relying Party websites and end users. In order to achieve that goal, we have been experimenting with new ways to improve OpenID usability and extend its functionality.

Our first enhancement, announced in January 2009, was to introduce the "Hybrid Protocol" API - combining OpenID's federated login with the OAuth access authorization. The Hybrid Protocol allows websites to ask Google to authenticate a user through their Google Account, while at the same time requesting access to information available via OAuth - enabled APIs such as the Google Data APIs. By combining the two protocols together, the Relying Party provides a better overall user experience and significantly reduces latency by cutting down the number of browser redirects and roundtrips. Plaxo, one of the websites using the Hybrid Protocol, published a presentation pointing out an amazing 92% success rate while experimenting with the API.

We are happy to announce today two new enhancements to our API - introducing a new popup style UI for our user facing approval page, and extending our Attribute Exchange support to include first and last name, country and preferred language.

The new popup style UI, which implements the OpenID User Interface Extension Specification, is designed to streamline the federated login experience for users. Specifically, it's designed to ensure that the context of the Relying Party website is always available and visible, even in the extreme case where a confused user closes the Google approval window. JanRain, a provider of OpenID solutions, is an early adopter of the new API, and already offers it as part of their RPX product. As demonstrated by UserVoice using JanRain's RPX, the initial step on the sign-in page of the Relying Party website is identical to that of the "full page" version, and does not require any changes in the Relying Party UI.


Once the user selects to sign in using his or her Google Account, the Google approval page is displayed. However, it does not replace the Relying Party's page in the main browser window. Instead it is displayed as a popup window on top of it. We have updated our Open Source project to include a complete Relying Party example, providing code for both the back-end (in Java) and front-end (javascript) components.


Once the user approves the request, the popup page closes, and the user is signed in to the Relying Party website.


Note that the popup style UI does not replace Google's existing full-page version, nor does it change the current behavior of our existing Relying Parties. It is up to the Relying Party to decide which of the two available formats they prefer, and modify their OpenID request accordingly as defined in the Google API Documentation.

As you can see in the screenshots provided, the user is not just signing in using her Google Account, but is also sharing specific information from her Google Account with the Relying Party website. This information may be either static fields (using Attribute Extension) such as the user's email, first and last name, preferred language and country, or allowing access to any available Google Data API such as the user's Contacts List, Web Albums, or Calendar (using OAuth). Google strongly believes that the data our users trust us with belongs to them and should always be available for them to use. By providing users with more secure means to share their data, they can benefit from a much more streamlined, personalized and socially relevant experience when they log in to trusted websites. At the same time, Relying Parties can significantly simplify their account creation and sign-in flows, resulting in happier users and higher successful registration rates.

If you want to know what's coming next and impact what the future advancements are, you are welcome to join the OpenID and OAuth mailing lists.

10 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. What I'm really waiting for is the ability to authenticate to google services with my own openid, instead of having to use a separate google account.

    e.g. I would like to associate my own openid with my google account, so I can login to gmail with my openid.

    ReplyDelete
  3. The new Popup UI is great, it's a lot less disruptive to the sign-in flow compared to the old redirect UI.

    ReplyDelete
  4. there's a bug in the implementation: when I navigate away from the login page while the popup is open and chose the "no thanks" button in the popup, the popup doesn't close and just displays a white page with no content.

    ReplyDelete
  5. Is there a plan to allow "normalized" profile URL of user as an OpenID so existing RP implementations can accept Google users? Please, pretty please!

    ReplyDelete
  6. Google still using Tiger? Come oooon

    ReplyDelete
  7. Loookin' awesome

    ReplyDelete
  8. Is there a fix to the "no thanks" bug?

    ReplyDelete
  9. Why cannot we sign with OpenID to Google ?

    ReplyDelete