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.
No comments:
Post a Comment