Google Hybrid OAuth/OpenID endpoint now available

For more detail, see
http://googledataapis.blogspot.com/2009/01/bringing-openid-and-oauth-together.html

User Experience for Strong Authentication

Eric Sachs & Ben Laurie, Google Security

One of the major conferences on Internet identity standards is the Internet Identity Workshop (IIW), a semiannual 'un-conference' where the sessions are not determined ahead of time. It is attended by a large set of people who work on Internet security and identity standards such as OAuth, OpenID, SAML, InfoCards, etc.  A major theme within the identity community this year has been about improving the user experience and growing the adoption of these technologies.  The OpenID community is making great progress on user experience, with Yahoo, AOL, and Google quickly improving the support they provide (read a summary from Joseph Smarr of Plaxo).  Similarly, the InfoCard community has been working on simplifying the user experience of InfoCard technology, including the updated CardSpace selector from Microsoft.

Another hot topic at IIW centered around how to improve the user experience when testing alternatives and enhancements to passwords to make them less susceptible to phishing attacks.  Many websites and enterprises have tried these password enhancements/alternatives, but they found that people complained that they were hard to use, or that they weren't portable enough for people who use multiple computers, including web cafes and smart phones.  We have published an article summarizing some of the community's current ideas for how to deploy these new authentication mechanisms using a multi-layered approach that minimizes additional work required by users.  We have also pulled together a set of videos showing how a number of these different approaches work with both web-based and desktop applications.  We hope this information will be helpful to other websites and enterprises who are concerned about phishing.

Overlap of identity technologies

One of the common requests I get is to describe how all the different identity technologies fit together.  I wrote up an initial draft of such an article a few weeks ago, and received a lot of feedback at the recent IIW conference, as well as from other people like Ashish Jain.  The article has now been updated to incorporate that feedback.

http://sites.google.com/site/oauthgoog/Overlap

iGoogle support for OAuth

Today Google announced that our iGoogle gadget platform provides native support for accessing OAuth enabled APIs.  AOL & MySpace both used this feature to create sophisticated gadgets that use OAuth APIs which they expose on their sites to those gadgets.  We also announced a few weeks ago that this feature can be used with the Google Data APIs which also all support OAuth.  We hope to convince more major websites to expose OAuth APIs that can be used by gadgets, as well as for other mashups by 3rd party developers.  Our Content Partnership team has already begun efforts to reach out to potential websites (http://contentcentral.blogspot.com/2008/11/share-information-securely-with-your.html).

While currently this feature does not support the Scalable OAuth extension which is required by some SPs such as Yahoo, we already have that working in our lab and hope to have it live on the iGoogle sandbox in the next 2-3 weeks.

We are looking for other interesting gadgets that developers can create which use this feature.  In particular, we are looking for interesting gadgets that mashup data from multiple OAuth SPs.  An even bigger challenge will be to create the first social gadget that uses the OAuth Proxy.  That feature is available on orkut.com, and it has also been contributed to the open source OpenSocial container called Shindig.  We have provided early documentation on how that feature can be used at http://sites.google.com/site/oauthgoog/oauth-proxy/social-oauthproxy, however we are waiting for some good examples before finalizing the documentation.

p.s. We also recently announced that our Enterprise E-mail outsourcing customers on GoogleAppsForYourDomain can enable 2-legged OAuth support, as well as the existing 3-legged OAuth support.  This feature has been much popular then expected, and is a good early sign of the potential for enterprise SaaS vendors to use OAuth as well.

Part 2 of our IDP announcement

Here is an update to our initial announcement of Google's OpenID IDP

Rich-client apps and federated login

Google's OpenID IDP is now live (for details see http://google-code-updates.blogspot.com/2008/10/google-moves-towards-single-sign-on.html) though for a short period of time we are requiring RPs to register before they use it, so we do not yet support automatic discovery.

Of course, I expect one other question a lot of people will ask is when might a large provider like Google become a relying party. Unfortunately there is one big, Huge, ENORMOUS PROBLEM! However it is fortunately mostly a problem of technology, and not as much usability. That problem is rich-client apps (desktop apps and mobile apps). All those Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for our enterprise E-mail outsourcing customers who run a SAML IDP, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.

If community members want to help in this area, please take a look at the research link below which we briefly discussed at the UX summit. A key thing to notice is that this research is about OAuth, and is agnostic to the particular federated login technology used, i.e. SAML or OpenID. It is also agnostic to the type of strong authentication method (if any) that is used to authenticate the user.

http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps

We need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If we build these components, they will be useful not only to Google, but also to any other relying parties which have rich-client apps or exposes APIs, and it will also help enterprise SaaS vendors like Salesforce.

If you want to help, send mail to the OpenID/OAuth mailing list to tell people what platform you are targeting in case others want to help. For example, Mike from Pownce did some work a few months ago to use OAuth on an iPhone and described how he got it working. Google has been working on a Windows C# implementation as described in that research documentation, so let us know if you want a copy of the code. Once you have identified a platform, then try to build an OAuth client app that accesses any OAuth enabled API from a vendor which supports OAuth today.

One such OAuth vendor is Google. For documentation on our OAuth support, see http://code.google.com/apis/gdata/auth.html#OAuth. However, you will notice that documentation only talks about web applications, and not rich-client applications. Google still has some work to do so that we properly support rich-client applications that want to use OAuth. For example, today developers of a rich-client app will need to register a web domain with us as the OAuth consumer, and then embed the OAuth Consumer Key/Secret in your app. In addition, the OAuth approval page we show will reference that website, instead of your app. The last key thing to note is that if you tried to make your client app available to a large set (100s of thousands) of end-users, the OAuth process on our side might break if a large set of them try to signup at the same time.

We plan to fix those UI and scaling shortcomings in the coming months, as well as probably support an anonymous Consumer Key/Secret since a commonly installed application would otherwise have the Key/Secret embedded in the code, and thus something a hacker could extract out of the app. But in the meantime, you can work around these limitations to build prototypes.

You may also notice that the prototype in our Desktop App research uses a Google proprietary API called ClientLogin for cases where the user is not authenticated via federated login. There has been some interest in the community to create a standard for that type of API using some parts of OAuth as well. So if you are interested in that topic, please share your ideas.

Google OpenID IDP is live

Here is the formal announcement of Google's OpenID IDP, including documentation and discussion group