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.