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

More on federated login user experience

As the identity community continues to share their UI/UX research into federated login, we are working to incorporate the research into our own publications. We recently updated our original federated login research with more information about signup buttons, tab ordering in login boxes, support for sites that requireunique usernames, and a checklist for sites that want to try out that login box UI.

We also published some thoughts on combining Google & Yahoo's OpenID UX research.

Rich-client apps, federated login, and OAuth

When we talk about federated login, one topic we tend to forget about is rich-client apps. Even as more applications move to web browsers, there are still many powerful applications for desktops and mobile devices. Google has published some user research about the use of rich-client apps with federated login, as well as a prototype. The prototype makes use of the client version of the OAuth standard.

UX Summit presentations

Last Monday (Oct 20th), Yahoo hosted a UX summit at their campus. Since that time Yahoo, MySpace, and Google have posted public copies of their presentations. You can find them linked off the agenda section of the UX summit webpage, or you can find them in the events section of the main oauthgoog site.

Usability Research on Federated Login

Federated login has been a goal of the Internet community for a long time, but its usage is still quite low, especially in the consumer space. This has led to the constant need for users to create yet another account to log in to a new website, and most consumers use the same password across websites even though they realize this is a poor security practice. In the enterprise space, many software-as-a-service vendors such as Salesforce.com and Google Apps for Your Domain do support federated login, but even those vendors encounter usability problems.

On September 12 the OpenID Foundation held a meeting to gather feedback on how to evolve the best practices for using OpenID so that it might be used by websites in a larger number of market segments. The meeting included representatives from many mainstream websites including The New York Times, BBC, AARP, Time Inc., and NPR. Google has been researching federated login techniques, and at the meeting we showed how a traditional login box might evolve (see below) to a new style of login box that better supports federated login.



We also shared a summary of our usability research that explains how this helps a website add support for federated login for some users without hurting usability for the rest of the website's user base. We hope that industry groups, such as this committee in the OpenID Foundation, will continue to share ideas and experiences so we can develop a model for federated login that can be broadly deployed by websites and broadly used by consumers. If your company has experience or research that you can share, we hope you will get involved with the OpenID community and join the further discussions on this topic.

Google OAuth & Federated Login Research

For those in the open source community interested in OAuth and Federated Login, the following sites contains a number of articles and presentations about Google's work in this area.  Some of this work overlaps with other open source efforts such as OpenID, Gadgets/OpenSocial, Caja, etc.

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

The purpose of this blog is to provide updates when new information is added to that site, or changes are made to the site.